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1.  INTRODUCTION:  NEEDS  AND  AREAS 


1 . 1 Needs  for  Research 

Within  the  broad  field  of  computer  programming,  one  need 
is  growing  particularly;  and  awareness  of  that  need  is 
also  growing.  That  need  is  the  facilitation  of  mainte- 
nance programming,  by  programmers  who  did  not  originally 
develop  a software  system,  on  software  which  others  have 
written. 

Several  factors  cause  the  need: 

(1)  As  programming  becomes  less  of  a pioneering 
work,  there  simply  are  more  programs  which  one 
may  modify  rather  than  develop  "from  scratch." 
Also,  as  telecommunications  are  improved  and 
as  computers  become  larger,  a tendency  is 
reported  (Hill,  1973)  for  specialized  software 
packages  to  be  shared  (and  modified)  by  a 
number  of  users. 

(2)  Personnel  turnover  has  traditionally  been  high 

in  programming.  While  it  may  have  declined  in 
recent  years,  it  is  still  high  in  relation  to 
other  professions:  One  study  (Simmons, 

1972)  estimates  that  twenty  percent  of  U.S. 
programmers  move  from  one  employer  to  another 
each  year. 

(3)  There  is  a tendency  for  software  systems  to 
become  more  ambitious;  and  larger  systems, 
according  to  Simmons  (1972)  amplify  the  need. 

High  costs  have  resulted  from  these  and  other  factors. 
For  the  U.S.  alone,  according  to  one  student  of  the 
problem  (Boehm,  1973) , annual  "...  software  costs 
. . . are  probably  over  $10  billion  . . 

Maintenance  programming  is  a major  factor  in  these 
costs.  The  U.S.A.F.  Systems  Command,  Electronic  Systems 
Division,  in  sponsoring  previous  research  in  this  area, 
estimated  that  the  maintenance  of  a large  computer 
program  often  costs  more,  over  the  life  of  the  program, 
than  was  paid  for  the  original  development  of  the 
program.  And  a recent  managers'  survey  (Rhodes,  1973) 
showed  that  the  typical  cost  of  developing  "a  big 
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system”  was  greatly  surpassed  by  the  costs  of  installing 
and  testing  it,  and  of  making  enhancements  in  it.  If 
published  estimates  can  be  believed,  this  all  implies 
that  maintenance  costs  the  U.S.  more  than  $5  billion 
per  year. 

In  spite  of  the  involvement  of  billions  of  dollars, 
there  has  been  a remarkable  lack  of  systematic  research 
into  the  conditions  which  help  and  hinder  people  doing 
maintenance  programming.  Electronic  Systems  Division, 
recognizing  this  lack,  has  sponsored  relevant  research 
(e.g.,  Overton  et  al.,  1973).  This  helped  correct  what 
was  earlier  described  as  ”...  an  applied  scientific 
lag  in  the  study  of  . . . programming  ....  a widening 
and  critical  lag  which  threatens  . . . great  waste  that 
inevitably  accompanies  the  absence  of  systematic  and 
established  methods  and  findings,  and  their  substitu- 
tion by  anecdotal  opinion,  vested  interests,  and 
provencialism"  (Sackman  et  al.,  1968). 

The  previous  research  identified  areas  which  promised 
particularly  great  potential  for  development — from  which 
helpful  tools  and  practical  advice  could  come.  The 
present  project  represents  further  work  in  two  of  those 
areas.  They  are  called  "Graphic  Terminal  Arrangements" 
and  "Automated  Conceptual  Groupings." 
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1.2  Areas  of  Research 


The  nature  of  the  work  reported  here* is  transitional, 
between  research  and  development.  One  area  (Conceptual 
Groupings)  includes  the  development  of  prototype  pro- 
grams which  could  be  converted  into  valuable  tools  for 
maintenance  programmers.  The  other  area  (Terminal 
Arrangements)  includes  research  into  the  conditions 
which  facilitate  problem-solving  in  programming. 


1.2.1  Graphic  Terminal  Arrangements 

Through  his  eyes  and  other  senses,  the  programmer  at  a 
terminal  takes  in  a variety  of  information.  The  inte- 
gration, or  lack  thereof,  of  this  information,  can  make 
the  programmer's  job  relatively  easy,  or  very  incon- 
venient. Thus,  this  area  of  research  concerned  the 
integration  of  the  information  used  by  the  person  at 
the  terminal. 

There  are  complex  interactions  between  the  physical 
arrangements,  the  programming  discipline  in  which  a 
person  is  working,  and  the  style  and  structure  of  the 
program.  This  research  sought  to  clarify  the  effects  of 
some  of  the  variables,  so  that  effective  arrangements 
can  be  devised  for  future  work  situations. 

In  addition  to  studying  the  basic  variables,  the  project 
also  pointed  out  some  specific,  smaller  features  of 
terminal  arrangements  which  are  both  helpful  and  harm- 
ful. 


1.2.2  Automated  Conceptual  Groupings 

When  one  programmer  is  talking  to  another,  explaining  a 
program  to  him,  much  of  his  explanation  is  cast  in 
interesting  units:  not  individual  statements  of  code, 

and  not  in  the  terms  of  the  formal  documentation  of  the 
program;  but  in  small  sets  of  statements,  each  set  of 
which  can  be  treated  as  a unit.  These  sets  have  been 
called  "Conceptual  Groups."  This  project  included  work 
on  programs  which  would  find  "Conceptual  Groupings" 
automatically . 

Two  pilot  versions  of  "Grouping  Programs"  were  written. 
Research  showed  that  such  programs  could  help  make  at 
least  certain  classes  of  applications  programs  sig- 
nificantly easier  to  maintain. 
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The  logic  of  the  programs  could  also  provide  the  designs 
by  which  compilers  could  be  modified,  so  that  the 
compilers  could,  by  helping  the  programmers,  reduce  the 
cost  of  maintaining  programs. 


2.  STUDIES  IN  GRAPHIC  TERMINAL  ARRANGEMENTS 


2 . 1 General  Themes 

Although  they  are  not  often  repeated  explicitly,  two 
general  themes  run  through  the  studies  in  terminal 
arrangements . 

First,  there  are  limitations  to  what  people's  senses 
can  perceive;  that,  both  literally  and  figuratively, 
eyes  have  to  blink  now  and  then;  that  some  things  are 
hard  to  see  and  follow;  and  that  people  may  get  tired 
of  trying. 

A second  theme  relates  to  more  intellectual  (as  opposed 
to  sensory)  functions.  Often,  the  difficulty  of  a 
problem  is  a function  of  the  way  it  is  presented.  And, 
in  a sense,  a terminal  is  a device  for  presenting  a 
problem,  or  a portion  of  a problem,  to  a maintenance 
programmer . 

The  first  (or  more  sensory)  theme  appears  strongly  in 
the  study  of  the  literature  (described  below)  relevant 
to  this  area,  and  in  the  direct  observations  of  the 
problems  of  maintenance  programmers  at  terminals. 

The  second  (or  more  intellectual)  theme  develops  into 
experimentation.  But  before  the  experiments  could  be 
executed,  a methodology  had  to  be  developed — problems 
had  to  be  presented  in  different  ways,  so  that  the  best 
feasible  way  could  be  found.  The  experimentation,  then, 
consisted  of  programmers  actually  working  on  programming 
problems  which  differed  significantly  and  systematically 
in  complexity  and  mode  of  presentation. 

The  two  themes  are  summed  up  in  the  phrase,  "sensory 
integration."  The  general  goal  is  to  present  informa- 
tion relevant  to  a maintenance  programming  problem  in 
the  way  in  which  the  information  is  easiest  for  people 
to  (1)  perceive,  and  (2)  integrate  into  a solution  to 
the  problem. 
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2 . 2 Research  Methodology 


The  following  activities  were  included  as  methods  of 
study  of  Terminal  Arrangements: 

, (1)  Relevant  literature  was  extensively  reviewed. 
(This  review  was  combined  with  that  for  the 
Conceptual  Groupings  studies.)  Basic  findings 
are  incorporated  in  the  body  of  this  report, 
but  additional  quotations  appear  in  Appendix  A. 

(2)  Concepts — especially  those  necessary  to  the 
making  of  specific  definitions  about  working 
conditions  and  performance — were  developed. 

(3)  Many  possible  experimental  variables  were 
refined  into  a tractable  number,  and  an  experi- 
mental design  was  developed. 

(4)  Observations — including  interviews — and  experi- 
ments— including  videotaping — were  conducted. 

(5)  Results  of  experiments  were  predicted  theo- 
retically, and  actual  results  were  compared 
with  the  theory. 

These  activities  are  discussed,  in  turn,  below. 


2.2.1  Literature  Review 

A wide  spectrum  of  sources  was  represented  in  the  lit- 
erature which  was  reviewed.  These  sources  may  be  roughly 
divided  into  four  classes: 

(1)  Professional  computing  journals.  Examples  in- 
clude the  IEEE  and  ACM  journals,  and  others  of 
lower  circulation. 

(2)  Other  professional  journals.  These,  such  as 
Perceptual  and  Motor  Skills,  may  contain  rele- 
vant  facts  while  not  being oriented  toward 
computers  or  programming. 

Popular  or  semi-professional  magazines.  A 
prime  example  is  Datamation.  (The  authors 
observe  that  many  popular  magazines  contain 
very  little  "firm"  information;  but  they  may 
be  of  value  in  reporting  current  opinions  and 
interests . ) 


(3) 
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(4)  Other  publications.  Included  are  books, 
dissertations,  and  symposium  proceedings. 

More  than  200  articles,  etc.,  were  read  during  the 
review.  (Of  course  a larger  number  were  merely  scanned 
briefly  or  skimmed,  and  rejected  as  being  not  worth 
perusing.)  These  were  converted  into  a file  of  relevant 
findings,  etc.  Where  appropriate,  these  were  incorpo- 
rated into  the  text  of  this  Final  Report. 

Several  of  the  sources  contained  "quotable  quotes"  which 
were  interesting,  but  which  would  not  fit  appropriately 
into  the  body  of  the  report.  Some  of  these  quotations 
were  copied  and  included  in  Appendix  A. 


2.2.2  Concept  Development 

One  of  the  problems  in  trying  to  study  maintenance  pro- 
gramming scientifically,  as  previously  observed  (Overton 
et  al. , 1973,  p.  84) 

"...  is  that  the  really  meaningful  elements  of 
the  work  are  difficult  to  define.  That  is,  the 
programmer  is  not  like  a factory  worker  who  is 
installing  components  that  can  be  counted  .... 

He  is  more  like  an  artisan  who  is  figuring  out  how 
to  make  or  repair  an  artifact.  (The  word  'arti- 
fact' is  used  in  its  archeological  sense,  as  'a 
product  of  human  workmanship.')  His  'figuring  out' 
is  hard  to  translate  into  anything  like  a quanti- 
tative statement  of  the  ingredients  in  his  problem- 
solving. 

"With  a time-sharing  system,  however,  the  pro- 
grammer enters  an  environment  in  which  one  element 
of  his  work  is  theoretically  subject  to  regular 
and  continual  measurement.  That  element  is 
information.  The  programmer  is  calling  for  in- 
formation  to  be  displayed  on  his  terminal.  He  is 
(mentally)  processing  that  information,  and  he 
is  throughputting  the  results  of  the  processed 
information  by  making  new  inputs  at  the  terminal." 

The  final  assumption  is  deceptively  simple:  The  more 

information  the  programmer  throughputs,  and  the  more 
accurately  he  does  it,  the  better  he  is  working. 

Unfortunately,  one  must  develop  more  specific  and  ob- 
servable concepts  before  one  can  use  this  assumption  as 
a guide  to  the  measurement  of  programmer  productivity. 

In  this  connection,  a new  body  of  literature  becomes 
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relevant.  It  is  that  on  "operator  workload":  the 

"load"  a man  can  "carry"  when  he  must  respond  to  inputs 
from  the  electronic  portions  of  a man-machine  system  of 
which  he  is  a part. 

A recent  review  of  this  literature  (Jahns,  1973)  empha- 
sizes the  diverse  origins  of  the  one  concept  of  the 
(sensory  and  intellectual)  "workload."  The  concept  is 
said  to  derive  from  four  different  classes  of  researchers 
and  theorists,  having  somewhat  different  meanings  for 
each  of  them.  The  four  are: 

(1)  Time-and-motion  analysts.  Using  a "scenario" 
as  a guide,  lengthy  predictions  of  the  exact 
tasks  with  which  an  operator  will  be  faced. 

They  also  predict  the  time  it  will  take  him  to 
do  each  action.  These  predictions  are  based 
on  normative  data  from  previous  studies.  The 
specialists  then  calculate  the  points  in  time 
when  he  simply  will  not  have  enough  time  to  do 
what  he  is  supposed  to  do. 

This  technique  is  said  to  " . . . provide  an 
adequate  tool  for  making  general,  broad  pre- 
dictions regarding  the  operator's  ability  to 
handle  a given  set  of  tasks." 

The  barrier  to  applying  this  technique  in 
maintenance  programming  is  that  one  does  not 
usually  know  in  advance  what  the  "given  set  of 
tasks"  will  be.  Also,  there  is  a lack  of 
normative  data  on  the  time  required  to  do 
various  tasks . 

(2)  "Channel  Capacity"  theorists.  It  is  assumed 
that  the  operator  works  within  a "channel 
capacity"  which  is  fixed  and  limited.  "Work- 
load" capacity  is  the  ability  to  accomplish 
additional  tasks,  whether  expected  or  unex- 
pected. 

This  approach  is  said  to  be  valuable  when 
applied  to  a small  number  of  individual  func- 
tions; but  it  may  distort  the  picture  if  it  is 
applied  to  "complex  interactions"  such  as  those 
found  in  "higher-order  man-machine  systems." 

This  approach  is  applicable  to  some  aspects  of 
maintenance  programming,  such  as  the  simple 
scanning  of  files  for  points  of  interest. 
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(3)  "Activation"  theorists.  Performance  is  said 
to  be  a function  of  the  activation  level,  or 
physiological  state,  of  the  operator. 

"The  results  obtained  so  far  are  promising  but 
fraught  with  problems  in  measurement  techniques, 
data  reduction  and  interpretation." 

In  the  opinion  of  the  authors,  this  approach 
has  no  place,  at  present,  in  the  study  of 
maintenance  programming. 

(4)  Non-theoreticians . It  is  assumed  that  any- 
thing which  will  "simplify"  the  work  situation 
will  help  the  operator.  Also,  any  situational 
change  which  improves  performance  is  assumed 
to  have  reduced  the  sensory/intellectual  work- 
load.' 

Now,  here  are  two  concepts  which  were  actually  used  in 
this  project,  and  their  relationship  to  the  concepts 
from  the  literature  as  reviewed  by  Jahns  (1973) . 

(1)  Information  sources.  The  screen  of  a terminal 
is  an  information  source,  as  is  a listing  of 
the  program.  As  will  be  seen,  there  are  other 
sources  of  information  which  are  quite 
important  to  the  maintenance  programmer. 

Within  the  time-and-motion  tradition,  it  is 
assumed  that  a programmer  can  work  better  when 
he  has  to  deal  with  a smaller  number  of  sources 
at  one  time,  and  when  each  is  as  convenient  to 
him  as  possible. 

(2)  Throughput  rate.  When  a maintenance  programmer 
looks  at  a new  item  on  a display,  he  has  to 
decide,  at  a minimum  whether  or  not  it  is  rele- 
vant to  what  he  is  doing  at  the  moment.  There 
is  a maximum  rate  at  which  he  can  make  such 
decisions,  and  this  rate  will  therefore  tend 

to  set  a pace  for  his  work. 

This  concept  is  compatible  with  that  of 
"channel  capacity."  The  authors  prefer  to 
express  the  throughput  rate,  wherever  it  is 
possible  to  do  so,  in  terms  of  bits  per  second. 

Another  concept,  unrelated  to  the  "workload"  literature, 
relates  to  people's  ability  at  "Keeping  Track  of  Several 
Things  at  Once"  (Yntema,  1963).  There  is  a limit  to 
this  ability  too;  and  it  becomes  very  relevant  to  a 
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maintenance  programmer  when  he  needs  simultaneously  to 
watch  more  than  one  source  of  information. 

A "proper"  experimental  design  is  based  upon  variables 
— controlled,  independent,  and  dependent  variables — and 
not  upon  general  concepts.  But  the  above  concepts  were 
used  in  evaluating  the  variables  described  below. 


2.2.3  Experimental  Variables  and  Design 

People  constantly  adapt  to,  and  overcome,  small  imper- 
fections in  their  equipment.  On  the  other  hand,  people 
also  respond  to,  and  are  distracted  by,  many  "non- 
signals" which  computers  ignore.  These  characteristics 
of  people  contributed  to  making  the  experimental  design 
(potentially)  extremely  complex.  Maintenance  pro- 
gramming is  simply  very  complex  behavior,  and  there  is 
no  realistic  way  around  this  fact. 

One  could  easily  list  more  than  a dozen  variables  (such 
as  those  cited  below)  which  influence  maintenance  pro- 
gramming. A necessary  task  was  the  refinement  of  these 
variables  into  those  which  were  most  basic. 

Then  an  experimental  design  (described  below)  was  de- 
veloped in  terms  of  the  basic  variables. 

Finally,  to  keep  the  results  from  being  unrealistically 
narrow,  experimentation  plus  observations  were  planned. 
(This  combination  is  also  described  below.) 


2. 2. 3.1  Variable  Refinement.  Preliminary  observations, 
coordinated  with  the  literature  review,  led  to  a formid- 
able list  of  independent  variables  upon  whose  effects 
the  productivity  and  success  of  maintenance  programmers 
might  in  part  depend.  These  include: 

(1)  Language.  The  pattern  of  errors  which  program- 
mers make  in  working  with  different  languages 
has  been  found  to  vary  from  language  to 
language  (Youngs,  1969) . FORTRAN  and  PL/1 
probably  differ  from  each  other,  and  from 
other  languages,  in  specific  aspects  of  main- 
tainability. 

(2)  Terminal.  A graphics  terminal  is  obviously  not 
equivalent,  in  terms  of  the  information  which 

a person  can  get  from  it,  and  the  way  he  can 
get  that  information,  to  older-style  print- 
outs and  "hard  copy."  The  terminal  itself  may 
affect  maintenance  behavior. 
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(3)  Other  information  sources.  Accessibility  of 
other  data,  such  as  printed  documentation,  may 
be  necessary  to  complement  the  information  re- 
ceived from  terminals  and  program  listings  (if 
any) . Ideally,  experimentation  should  cover 
these  other  information  sources. 

(4)  Program  application.  Payroll  programs  have  been 
written  in  both  FORTRAN  and  COBOL,  as  well  as 

in  PL/1  and  other  languages . Within  the  frame- 
work of  one  language,  the  application  area  may 
affect  maintainability.  And  there  obviously 
are  different  types  of  applications,  including 
TU  business,  (2)  scientific,  (3)  statistical, 

(4)  simulation,  and  (5)  others. 

(5)  Size.  It  seems  reasonable  to  suppose  that  a 
big  program  should  be  harder  to  maintain  than 
a small  one,  but  there  are  no  "hard"  data  on 
the  relationship  between  maintainability  and 
size.  Conceivably,  this  experimentation  might 
seek  to  generate  such  data. 

(6)  Style.  Under  at  least  some  conditions,  pro- 
grammers prefer  to  work  on  programs  which  are 
written  in  a highly  modular,  hierarchical  style 
(Overton  et  al.,  1973).  Hence  aspects  of  style, 
such  as  degree  of  modularization,  are  candi- 
dates for  experimental  variables. 

(7)  Test  difficulty.  A commonly-expressed  opinion 
is  that,  especially  with  larger  software 
systems,  the  ease  of  maintenance  work  depends 
in  part  on  the  availability  of  test  data,  and 
the  convenience  of  test  conditions. 

(8)  Complexity.  One  program  may  differ  consider- 
ably from  another  in  terms  of  logical  conse- 
quences and  complexity  per  unit  of  code.  For 
example,  two  programs  might  each  keep  records 
on  the  locations  of  various  particles  or  units. 
One  might  do  so  in  a simple  inventory  control 
program;  the  other  might  employ  a set  of 
differential  equations  to  model  the  three- 
dimensional  diffusion  of  gaseous  particles. 

The  latter  would  probably  be  the  more  complex 
program,  even  though  the  former  might  be  longer 
in  terms  of  number  of  program  statements. 

Now  one  could  easily  imagine  an  experiment,  designed  to 
cover  reasonable  points  in  the  above  variables,  which 
employed  (1)  three  programming  languages,  (2)  two  terminal 
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situations,  (3)  two  other  information  sources,  (4)  two 
program  application  areas,  (5)  two  sizes,  (6)  two  styles, 
(7)  two  degrees  of  test  difficulty,  and  (8)  two  degrees 
of  complexity.  This  experimental  design  would  require 
that  data  be  taken  under  the  number  of  different  con- 
ditions which  is  the  product  of  the  numbers  just  listed; 
namely,  384. 

If  one  decided  to  observe,  as  a reasonable  amount,  12 
hours  of  programming  activity  (presumably  assigned  to 
different  programmers  in  such  a way  as  to  preclude  the 
creation  of  other  problems  in  interpreting  the  results) 
in  each  condition,  then  one  would  require  4,608  programmer 
hours  of  work  to  be  observed  in  the  experiment. 

This  amount  of  work  (not  to  mention  the  equally  formid- 
able problems  in  setting  up  all  those  conditions,  and 
in  scheduling  them)  would  make  the  experiment  far  too 
expensive  to  be  seriously  considered. 

The  practical  problem,  then,  is  one  of  boiling  down 
. . . : refining  the  variables  into  a tractable  number, 

and  then  converting  that  number  into  an  experimental 
design.  (As  noted  below,  the  formal  experimentation 
was  supplemented  by  further  observations.) 

During  the  course  of  the  first  four  months  of  the  pro- 
ject, personnel  from  Electronic  Systems  Division  advised 
those  from  AMS  regarding  the  languages  of  greatest  in- 
terest to  the  government;  and  AMS  personnel  used  the 
findings  from  the  literature,  plus  the  results  of  pre- 
liminary observations  and  interviews,  to  refine  the 
other  potential  experimental  variables. 

As  a result  of  this  work,  the  following  decisions  were 
made. 

(1)  It  was  decided  early  that,  for  both  the  Termi- 
nal Arrangements  and  Conceptual  Groupings 
studies,  the  languages  of  primary  interest 
would  be  PL/1  and  FORTRAN . For  Terminal 
Arrangements,  experimentation  was  restricted 
to  FORTRAN. 

(2)  Based  largely  on  its  prominence  in  the  litera- 
ture, an  aspect  of  style  was  chosen  as  an  in- 
dependent variable.  That  aspect  was  degree  of 
modularity  in  the  programs  used. 

- t. 

It  was  noted  that  this  variable  tends  to  be 
correlated  with  degree  of  structure,  and  with 
the  extent  to  which  a software  system  is 
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organized  in  a hierarchical  manner.  That  is, 
highly  modular  programs  are  compatible  with 
so-called  "structured  programming, " although 
modular  programs  can  be  produced  without 
following  the  rules  of  structured  programming 
(Liskov,  1972)  . 

(3)  Based  largely  on  the  first  four  months'  inter- 
views and  observation,  attention  was  also 
focused  on  the  rather  broad  variable  of  "choice 
complexity"  prevailing  within  the  program;  or, 
more  precisely,  of  the  per-unit  complexity 
characterizing  the  software  being  maintained. 

In  other  words,  modularity  and  complexity  represent  the 
independent  variables,  whose  effects  were  to  be  studied. 
The  dependent  variables,  to  be  observed  and  quantified 
as  much  as  possible,  related  to  programmer  performance 
and  efficiency. 

The  method  for  quantifying  programmer  performance  was 
not  fully  developed  until  after  the  completion  of  a 
number  of  preliminary  observations.  No  method  of  quan- 
tification was  really  satisfactory;  a number  were  con- 
sidered. 

Number  of  modifications,  per  unit  of  time,  was  rejected 
because  of  differences  in  the  types  and  sizes  of  modi- 
fications to  be  made. 

Number  of  entries,  per  unit  of  time,  was  studied  at 
length  and  rejected  because  of  the  problem  of  defining 
"entry."  A long  series  of  numbers  might  be  just  as 
legitimate  a single  entry  as  one  character  in  a state- 
ment. Also,  some  entries  might  be  made  in  almost  random 
experimentation  by  a confused  programmer. 

A crude  and  subjective  method,  which  was  used,  involved 
the  programmer's  opinion,  which  was  obtained  at  the  end 
of  a session  at  the  terminal.  Some  programmers  (notably, 
the  one  with  the  most  formal  education)  spontaneously 
made  comments  at  the  end  of  each  session,  saying  things 
like  "Well,  that  should  take  care  of  that";  or,  "I  don't 
know  what  happened  there."  If  a programmer  volunteered 
such  a comment,  he  was  not  asked  about  his  progress. 

If  he  did  not,  he  was  asked,  "Well,  did  it  (glancing  at 
the  terminal)  let  you  do  what  you  expected  to?" 

Comments  were  coded  in  terms  of  "good"  for  a clear  yes , 
"so-so"  for  an  indication  of  something  like  half-way 
satisfaction,  and  a "bad"  for  a clear  no. 
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A more  objective  method,  which  was  used,  involved  the 
concept  of  "getting  stuck."  The  maintenance  programmer 
was  said  to  be  "stuck,"  and  "spinning  his  wheels,"  if  he 
did  any  one  of  the  following  things: 

(1)  ...  sat  at  the  terminal,  taking  no  control 
actions,  with  nothing  new  coming  from  the 
computer,  for  at  least  45  seconds. 

The  time  threshold  of  45  seconds  was  selected 
on  the  basis  of  (a)  previous  results  showing  a 
somewhat  comparable  median  study  time  of  about 
half  a minute  (Overton  et  al.,  1973);  and 
(b)  its  seeming  reasonable  as  judged  from  pre- 
liminary observations. 

(2)  ...  went  away  from  the  terminal  to  study  a 
reference  manual  or  other  general  documentation, 
or  otherwise  "left  the  field." 

(3)  ...  without  expressed  or  apparent  purpose, 
paged  rapidly  through  a listing  or  files  for 
at  least  90  seconds  (which  is  twice  the  no- 
action threshold) . 

To  cast  this  measure  in  a more  useful  and  positive  form, 
the  "productive  time,"  or  time  before  getting  stuck,  was 
noted.  (If  a programmer  did  not  get  stuck  in  the  last 
M minutes  before  ending  a session,  this  was  noted  as 
M-E,  where  "E"  stands  for  "End.")  Distribution  of  pro- 
ductive time  was  then  used  to  study  programmer  efficiency 
under  the  experimental  conditions. 


2.2.3. 2 Design  of  Experiment.  Given  the  above, 
important  decisions,  the  design  of  the  plan  for  the  ex- 
perimental observations  became  a relatively  simple  job. 

In  order  to  represent  more  than  one  point  on  each  of  the 
independent  variables,  but  at  the  same  time  keep  the 
total  experimental  time  within  the  constraints  set  up 
by  the  limited  availability  of  experimental  programmers, 
a simple  "two-by-two"  design  was  developed.  It  is 
summarized  in  Figure  1. 

Ideally,  only  two  programs  would  have  been  used  in  the 
experimental  design:  one  of  high  intrinsic  per/unit  com- 

plexity, and  another,  comparable  in  length  and  every 
other  respect,  of  low  per/unit  complexity.  Then  two 
versions  of  each  program  would  have  been  written:  one 

of  high  modularity,  and  another  low-modularity  version. 
Finally,  the  four  program/ vers ions  would  have  been  used 
in  the  corresponding  four  "cells"  in  Figure  1. 
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Low  modularity 
condition 

High  modularity 
condition 

High  complexity 
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Results 

Results 

Low  complexity 
condition 

Results 

Results 

Figure  1.  Terminal  Observations  Experimental  Design 


Some  very  practical  reasons  prevented  this  ideal  from 
being  met.  For  one  thing,  special  programs,  not  con- 
nected with  the  real  daily  work  of  the  maintenance  pro- 
grammers, would  have  meant  that  they  were  working  in  a 
very  artificial,  "test-tube"  type  of  situation  of  which 
they  would  have  been  painfully  aware?  so  the  results  may 
have  been  unrealistic  and  suspect.  Other  reasons  were 
essentially  economic:  In  effect,  four  new  programs 

would  have  to  have  been  developed,  tested,  scheduled, 
etc.;  and  the  money  was  not  available  for  this  kind  of 
effort.  As  a result,  real  programs,  currently  being 
maintained  at  the  test  sites,  were  selected  on  the  basis 
of  their  being  comparable  in  aspects  other  than  com- 
plexity and  modularity. 

The  general  working  environment  of  the  maintenance  pro- 
grammer is  this:  Essentially,  he  is  tracing  the  pro- 

gram's manipulation  of  data — ranging  from  bits  to  files. 
His  purpose  is  to  "understand"  the  program's  modes  of 
manipulation,  but  to  understand  them  only  to  the  limited 
extent  necessary  to  let  him  attain  his  narrow  goal : to 

make  a successful  modification. 

The  modification  is  deemed  successful  if  it  (1)  "works" 
in  its  own  right — does  what  it  was  added  to  do;  and 
(2)  does  not  "foul  up"  or  cause  new  errors  in  other 
parts  of  the  program. 

In  doing  this  maintenance,  the  programmer  is  using  a 
graphics  terminal  connected  to  a time-sharing  computer 
system.  Within  the  constraints  of  the  screen  and  the 
system,  the  programmer  can  look  at  input  data,  the  pro- 
gram (whose  length  is  in  the  low  thousands  of  statements) , 
and  at  files  being  created  by  the  program. 

The  dependent  variables  (or,  in  terms  of  Figure  1,  "re- 
sults") center  around  the  rate  at  which  the  maintenance 
programmer  makes  progress  toward  his  goal.  These  were 
measured  in  terms  of  the  subjective  reports  by  the  pro- 
grammer, and  in  terms  of  more  objective  measures  such 
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as  pace  of  work  and  frequency  of  significant  problems 
and  long  interruptions. 


2 .2. 3. 3 Other  Observations.  AMS  emphasizes  that  the 
experimental  design  in  Figure  1 focuses  on  only  a small 
portion  of  the  interactions  and  variables  which  were 
listed  prior  to  Figure  1.  More  crudely  speaking,  that 
experimental  design  illuminates  only  a small  portion  of 
the  field  of  maintenance  programming. 

To  expand  that  "portion  of  the  field,"  informal  obser- 
vations were  made  regarding  variables  and  factors  not 
covered  in  the  formal  design.  This  observation  covered 
all  of  the  "cells"  in  the  design,  plus  a large  number 
of  instances  of  maintenance  which  were  not  included  in 
the  formal  design. 

The  advantage  of  the  experimentation,  of  course,  if  its 
potentiality  for  yielding  objective  results.  The  ad- 
vantage of  the  other  observations,  which  may  fail  to 
produce  significant  data,  is  that  they  may  cover  a 
larger  and  more  realistic  variety  of  considerations. 


2.2.4  Execution  of  Method 

Observations,  by  AMS  personnel  of  other  companies' 
employees  in  maintenance  programming,  were  conducted  at 
the  following  locations.  (They  are  listed  in  approxi- 
mate decreasing  order  of  the  extent  of  the  observations 
and  their  value  to  this  project;  this  ranking  does  not 
imply  any  judgments  regarding  the  intrinsic  merits  and 
abilities  of  the  companies.) 

(1)  General  Dynamics/San  Diego 

(2)  Copley  Computer  Services,  Inc. 

(3)  University  of  California  at  San  Diego 

(4)  Diaspar  Data  Services,  Inc. 

(5)  Professional  On-Line  Systems,  Inc. 

(6)  University  of  California  at  Irvine 

(7)  Basic  Four  Corporation 

(8)  McDonnell  Douglas  Automation  Co. 
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(9)  TRW  Systems 

(10)  California  Computer  Products,  Inc. 

Not  counting  travel,  time  for  analysis  of  notes  and 
tapes,  etc.,  the  "observations"  included 

(1)  approximately  40  hours  of  interviews; 

(2)  approximately  48  hours  of  observations  which 
were  not  videotaped,  or  for  which  the  video- 
tapes were  not  usable; 

(3)  8 hours  of  videotaped  experimentation. 

Videotaping  was  done  on  a Sony  2000-series  recorder. 

It  was  later  viewed,  for  analysis,  on  a compatible 
player  borrowed  from  the  Capistrano  Unified  School 
District. 

Notes  and  records  were  analyzed  in  AMS  offices. 

Most  of  the  notes  consisted  of  handwritten  abbrevia- 
tions which  were  barely  intelligible  to  anyone  except 
their  authors.  To  illustrate  the  notes,  one  segment  was 
"interpreted"  and  typed.  It  is  reproduced  as  Figure  2. 


2.2.5  Theoretical  Comparisons 

Independently  of  the  execution  of  the  experimental 
method,  the  relevant  published  literature  was  again  re 
viewed  to  see  what  results  would  theoretically  be 
expected. 


2. 2. 5.1  Purpose . The  purpose  of  this  phase  of  the  pro- 
ject was  to  supplement  the  actual,  experimental  results. 
Because  of  the  necessarily  limited  scope  of  the  formal 
experimentation,  it  was  deemed  especially  important  to 
compare  them  with  whatever  theoretical  predictions  of 
the  results  the  available  literature  might  permit  one 
to  make. 


2. 2. 5. 2 Procedure.  While  there  almost  are  no  "hard" 
data  on  the  problems  of  maintenance  programming  with 
simple-versus-complex  and  modularized-versus-other  pro- 
grams, data  do  exist  on  problem-solving  in  a variety  of 
other  situations.  Those  situations  which  were  the  most 
analagous  to  maintenance  programming  were  sought,  and 
the  findings  on  those  situations  were  reviewed. 
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O:  Today  is  11  April.  This  is  the  same  program  as 

9 April. 

P:  This  file  is  too  large.  I'm  going  to  reduce  it. 

0:  He  sees  that  it  is  too  large  from  the  hard  copy. 

P:  I'll  get  the  source  file,  make  an  absolute  over- 

lay, and  hope  the  loader  will  fit  it.  But  the 
loader  is  large. 

P:  I'll  reduce  it  by  two  changes. 

0:  Both  figured  out  at  his  desk.  I wonder  where  is 

the  best  place  to  think. 

P:  I'll  remove  the  data  file. 

0:  And  also  use  the  absolute  overlay.  That's  the 

second  change. 

0 : He's  trying  to  load  something  from  the  terminal . 

C:  Uses  LDSET  to  locate  the  plotting  software. 

C:  Goes  past  a time  limit,  cites  limit,  stops. 

P:  I'll  print  OUTPUT  to  get  a listing. 

0:  For  future  study. 

P:  I'll  catalog  this  file  and  go  to  the  editor  to 

enter  this  control  card  stream. 

0:  He  enters  nine  lines  and  then  an  = symbol.  A lot 

of  characters  for  a man  to  remember. 

C:  Attaches  file.  (Computer  is  slow  due  to  one 

large  job.) 

0:  What  are  you  looking  for? 

P:  The  thing  that  tells  the  size  of  the  program. 

C:  Fills  screen,  then  re-formats  display. 

P:  Types  '450'  to  list  programs. 

P:  Damn!  It's  larger  than  the  other  one! 

P:  I'll  go  back  to  the  other  change. 

0:  Taking  out  some  data  file. 

P:  I'll  tell  it  to  keep  my  personal  file  . . . not 

the  user's  file. 

0:  When  he  bends  over  to  the  side  to  look  at  the 

listing,  his  head  blocks  out  the  video. 

P:  Check  against  these  constants.  . . . 

0:  Using  variable  names  for  clarity. 

P:  I'll  dimension  another  variable. 

0:  To  reduce  the  file  size. 

P:  This  makes  the  previous  patch  more  efficient. 

That' s the  patch  which  tells  it  not  to  plot  a 
curve  between  two  points. 

0:  Only  more  than  two. 


Figure  2.  Example  of  Notes  Supplementing  Video 
Tapes  of  Terminal  Arrangements  Study 

Key:  0 = Observer's  impression 

P = Programmer ' s comment 
C = Computer  or  machine  action 


3.  GRAPHIC  TERMINAL  STUDY  RESULTS 


3 . 1 Opinions  from  the  Field 

The  polling  of  opinions,  from  a technical  version  of 
George  Gallup's  samples,  was  not  the  intent  of  this 
project.  Nevertheless,  collection  of  some  opinions  from 
maintenance  programmers  and  their  supervisors  was  a con- 
venient by-product  of  the  "Other  Observations"  cited  in 
the  methodology.  Some  opinions,  which  are  more  or  less 
consensual,  are  reported  here. 


3.1.1  Need  for  Tools 

Maintenance  programmers  say  more  and  better  tools  for 
terminals  are  needed,  especially  in  the  graphics  area. 

Tools  mentioned  as  desirable  included  support  routines 
to  insert  lines,  check  format,  check  input,  etc. 

Available  tools  in  these  areas  were  criticized  on  at 
least  two  counts:  Documentation  of  the  tools  is  poor, 

so  that  a new  programmer  tends  not  to  use  them;  and,  the 
tools  are  not  sufficiently  standard  and  transportable; 
they  are  too  restricted  to  specific  devices  and  in- 
stallations. (This  latter  complaint  was  made  with  par- 
ticular strength.) 

Better  paging  and  file  search  routines  were  also  requested. 
On  the  basis  of  the  present  authors'  observations,  these 
would  indeed  have  been  used  extensively. 

Difficulties  were  cited  in  getting  technical  data  from 
manufacturers  about  specific  hardward  features,  such  as 
the  treatment  of  interrupts,  of  concern  to  programmers. 

Some  programmers  said  that  the  program  documentation  for 
the  users  was  generally  better  than  the  documentation 
for  the  maintainers. 

McDonnell  Douglas  Automation  Company  had  developed,  and 
was  beginning  maintenance  on,  a large,  interactive 
graphic  diagramming  system.  Because  of  problems  with 
available  tools,  their  personnel  had  developed  many  of 
their  own  tools;  included  was  a rather  powerful  text 
editor. 
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An  available  text  editor  used  in  three  other  companies 
was  indeed  powerful,  but  programmers  said  it  was  incon- 
venient to  use.  Actually,  it  is  probably  even  more  in- 
convenient than  the  programmers  realized;  they  had 
adapted  to  some  of  its  peculiarities.  But  programmers 
in  different  companies  seemed  to  be  using  different  sub- 
sets of  its  features , perhaps  because  each  installation 
became  acquainted  only  with  the  features  which  happened, 
at  first,  to  seem  most  useful  to  their  "shop." 

At  Copley  Computer  Systems,  Inc.,  "edit  tables"  were 
under  development.  These  will  allow  a programmer,  be- 
ginning a "run,"  to  specify  which  of  a group  of  features 
he  wants  included  in  the  run.  The  tool  will  contribute 
to  computerized  report-writing;  it  will  allow  the  pro- 
grammer to  generate  alternate  modified  report  formats 
more  easily,  and  thus  to  get  easier  confirmation  from 
the  user  that  the  modification  meets  his  requirements. 

One  installation  had  a graphics  package,  designed  to 
help  engineers  design  and  draw  electronics  circuits, 
which  included  a "zoom"  option:  It  magnified  a portion 

of  the  display.  The  option  was  intended  primarily  for 
the  engineers , and  the  programmers  said  they  rarely 

used  it  in  maintenance  work. 

r 

The  tool  (if  it  can  be  called  a tool)  which  seemed  to 
be  used  most  frequently  was  simply  the  provision  for  the 
setting  of  break-points  in  applications  programs. 


3.1.2  Preferred  Procedures 

A manager  at  Copley  said  that  their  on-line  system 
made  maintenance  work  go  about  ten  times  as  fast  as  it 
had  on  a previous  batch  processing  system.  To  the 
present  authors,  who  of  course  studied  the  system  there 
in  much  less  detail  than  did  the  manager  there,  the 
Copley  system  and  procedures  did  indeed  seem  extremely 
efficient. 

Emphasis  was  placed  on  "sections"  of  code,  each  of  which 
performed  one  and  only  one  function. 

The  sections  were  quite  small.  Some  were  only  two 
lines  in  length;  the  mode  seemed  to  be  about  six,  and 
the  maximum  was  said  to  be  40  or  50  lines  of  code. 

Because  of  their  small  size,  the  sections  were  par- 
ticularly effective  with  an  on-line  system,  because 
. . . : (1)  A section  is  small  enough  to  be  keyed  into 

the  terminal  quickly.  (2)  It  can  also  be  output  quickly. 
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(3)  Since  it  performs  only  one  function,  the  maintainer 
can  debug  it  separately.  (4)  It  is  easy  to  find  the 
section  which  contains  an  error  if  its  function  is  not 
performed  correctly. 

Documentation  "is  always  done  before  and  during  the 
process  of  developing  the  program — little,  if  any,  re- 
mains to  be  done  afterward." 

The  Copley  computing  center  uses  no  cards  at  all.  At 
another  installation,  the  use  of  magnetic  tape  rather 
than  cards  was  advocated  to  facilitate  maintenance.  The 
tape  was  said  to  give  more  rapid  feedback  to  the  pro- 
grammer. It  also  made  it  easier  to  keep  different 
versions  of  a program  distinct  and  well  identified. 


3.1.3  Where  People  Think 

An  analyst  at  Copley  said  they  "very  seldom  write  any- 
thing on  paper"  before  keying  statements  into  the  termi- 
nal. In  other  words,  they  think  at  the  terminal. 

Exceptions  were  said  to  be  "tricky  little  routines." 
These  were  analyzed  at  the  programmer's  desk  before  he 
turned  to  the  terminal. 

At  other  installations,  the  general  picture  was  quite 
consistent.  The  normal  mode  of  operation  is  for  a pro- 
grammer to  do  the  most  difficult  thinking  and  analysis 
at  his  desk;  he  plans  to  do  more  routine  work  at  the 
terminal . 

With  complex  programs,  he  is  not  always  able  to  follow 
his  plans:  Sometimes  he  faces  challenging  problems  at 

the  terminal.  But  the  general  tendency  (whatever  the 
reason  may  be)  is  for  programmers  to  assume  that  they 
will  do  their  deeper  thinking  at  their  desks. 

Plans  for  that  thinking  may  come  from  the  terminal.  At 
Copley,  a programmer,  who  said  he  did  no  handwriting  at 
the  terminal,  nevertheless  made  notes  on  a program 
listing  to  help  him  plan  further  changes.  This  was  also 
a common  practice  elsewhere. 


3.1.4  Other  Opinions 

After  the  experimentation  (reported  in  the  next  section) , 
or  when  talking  with  programmers  not  involved  in  the 
study,  we  raised  the  subject  of  programming  languages. 
Their  relationship  to  the  difficulty  of  maintenance  was 
of  special  interest. 
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A surprising  opinion  was  that  BASIC  should  be  more  widely 
used.  Its  many  default  options,  particularly  on  number 
formats  with  which  the  maintainer  may  not  be  familiar, 
were  cited  as  a primary  reason.  One  programmer  pre- 
dicted that  the  Digital  Equipment  Corporation  full- 
compile  BASIC  will  be  a dominant  language  within  five 
years. 

Finally,  it  was  noted  that  beginners  are  sometimes  a 
little  afraid  of  the  terminal.  A similar  point  was 
made  in  a magazine  article  about  reactions  to  an  inter- 
active graphics  system.  The  article  declared  that 
people  often  "...  felt  they  were  in  a race  with  the 
computer.  It  was  as  if,  when  they  looked  at  the  termi- 
nal screen,  they  saw  all  the  way  through  to  the  central 
processor  unit  and  a million  dollars  worth  of  electronics 
staring  back  at  them,  which  they  felt  obligated  to  use 
efficiently."  (Franklin  & Dean,  1974,  p.  9.) 

At  some  installations,  we  saw  none  of  this.  For  example, 
the  experienced  programmers  at  Copley  and  at  Diaspar 
Data  Services  seemed  quite  comfortable  at  their  termi- 
nals. 


3 . 2 Results  from  Experimental  Design 


The  data  from  the  Terminal  Arrangements  experimental 
design,  supplemented  by  the  theoretical  comparisons, 
produced  these  areas  of  findings: 

(1)  Of  the  experimental  design  variables  of  degree 
of  modularity  and  per-unit  program  complexity, 
complexity  seemed  to  have  the  greater  effect 
on  ease  of  work.  The  programmers'  pace  of 
work  was  most  regular  in  the  high-modular/low- 
complexity  condition.  Other  factors,  such  as 
the  availability  of  tools,  may  often  be  at 
least  as  important  as  modularity. 

(2)  For  complex  programs,  an  extremely  high  degree 
of  modularity  could  be  recommended  on  the 
basis  of  these  results  and  findings  from  the 
literature. 

These  areas  of  findings  are  described  further,  below. 


3.2.1  Effects  of  Variables 

! 

The  overall  results  were  not  surprising:  Complex  pro- 

grams are  harder  to  maintain,  and  so  are  programs  of 
low  modularity.  Later  discussion  will  indicate  that  the 
full  picture  of  the  effects  of  such  variables  is  proba- 
bly broader  than  that  given  by  the  narrow  experimental 
design  results. 


3. 2. 1.1  Results . A clear  form  of  the  results  is  pre- 
sented in  Figure  3a.  Here  the  numbers  are  percentages; 
the  overall  average  productive  time  for  all  conditions 
represents  100%,  and  the  average  productive  time  within 
each  of  the  four  "cells"  is  stated  as  a deviation  from 
that  overall  average. 

The  table  is  self-explanatory.  For  example,  it  can  be 
seen  that  most  of  the  effect  due  to  modularity  appears 
in  the  low-complexity  condition.  (As  will  be  noted 
later,  this  is  contrary  to  what  one  would  theoretically 
expect.)  Similarly,  the  greatest  difference  is  found 
between  the  conditions  of  high-complexity/low-modularity 
and  low-complexity/high-modularity.  (This  was  expected 
theoretically. ) 

The  percentage  data  in  Figure  3a  are  derived  from  the 
productive  time  data  shown  in  Figure  3b.  This  latter 
figure  also  groups  the  "raw  data"  for  productive  time 
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"E"  following  a number  indicates  that  the  session 
ended  with  the  completion  of  that  productive  time. 
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together  with  the  maintenance  programmer's  evaluation 
(in  terms  of  "good,"  "so-so,"  and  "bad")  of  his  success 
in  the  session  at  which  the  data  were  taken.  General 
agreement  is  seen  between  the  productive  time  data  and 
the  programmer ' s independent  evaluations . 

Because  of  the  probable  abnormal  distribution  of  time 
data,  and  because  of  the  small  sample  size,  conventional 
tests  of  statistical  significance  (such  as  analysis  of 
variance)  were  not  performed  on  the  data  in  Figure  3b. 


3. 2. 1.2  Discussion . The  lack  of  a very  strong  effect 
due  to  modularity,  at  least  for  the  ranges  of  modularity 
and  other  conditions  involved  in  this  study,  is 
interesting  in  the  light  of  other  opinions  and  findings. 
Interviews  with  maintenance  programmers,  reported 
earlier,  indicated  that  many  programmers  would  like  to 
see  more  tools,  and  more  standardized  tools,  for  use  at 
graphics  terminals.  Some  programmers  praised  modulari- 
zation, but  a larger  number — perhaps  only  because  they 
tended  to  think  of  tools  to  help  them,  rather  than 
styles  to  be  imposed  on  them — -called  for  better  software 
tools.  (What  is  "better"  is  often  a matter  of  opinion; 
there  are  few  studies,  like  the  experimentation  with 
Conceptual  Groupings,  which  actually  indicate  that  a 
tool  improves  productivity.) 

Another  survey  independently  confirmed  the  widespread 
opinion  that  tools  have  a relatively  great  effect  on 
programmer  productivity  (Scott  & Simmons,  1974).  In 
particular,  tools  were  generally  believed  to  be  much 
more  important  than  programming  which  is  free  of  GO-TO's, 
and  which  is  developed  in  a style  which  should  be 
compatible  with  high  modularity. 

In  summary,  the  practical  effect  of  modularity  is  a 
complex  function  of  the  exact  degree  of  modularity 
in  interaction  with  other  variables  of  the  program, 
language,  and  supporting  environment. 


3.2.2  Comparison  with  Theory 

In  brief,  the  theory  (from  the  literature)  led  to  three 
predictions : 

(1)  that  people  have  a general  predilection  for 

hierarchical  memory  structures  in  themselves, 
and  that  this  predilection  should  make  it 
easier  for  programmers  to  work  on  the  more 
modular  programs; 
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(2)  that  simple  programs  are  intrinsically  easier 
to  modify  than  those  representing  complex 
phenomena;  and 

(3)  that  the  advantages  of  modular  programming 
should  be  greater  with  complex  than  with  simple 
programs . 

The  actual  results  tended  to  support  the  first  two  of 
these  predictions.  The  third  prediction  was  not  supported; 
this  disparity  between  theory  and  experience  may  have 
arisen  because  a different  range  of  "modularity"  may  be 
needed  for  programs  of  high  per-unit  complexity. 

, The  following  paragraphs  describe  (1)  the  theoretical 
background,  (2)  the  making  of  the  above  predictions,  and 
(3)  discussion  based  on  further  comparison  with  the 
actual  results. 


3. 2.2.1  Background.  The  mathematician  Henri  Poincar6 
was  not  a good  chess  player;  his  memory  was  not  good 
enough  1 He  explains  why  his  memory  was  nevertheless 
adequate  for  his  work  as  a mathematician  of  the  first 
rank: 

"A  mathematican  demonstration  is  not  a simple 
juxtaposition  of  syllogisms,  it  is  syllogisms  placed 
in  a certain  order,  and  the  order  in  which  these 
elements  are  placed  is  much  more  important  that 
the  elements  themselves.  If  I have  the  feeling, 
the  intuition,  so  to  speak,  of  this  order,  so  as  to 
perceive  at  a glance  the  reasoning  as  a whole,  I 
need  no  longer  fear  lest  I forget  one  of  the  ele- 
ments, for  each  of  them  will  take  its  allotted 
place  in  the  array,  and  that  without  any  effort 
of  memory  on  my  part.  It  seems  to  me  then,  in 
repeating  a reasoning  learned,  that  I could  have 
invented  it."  (Poincare,  1913) 

Poincare's  quotation  illustrates  a rather  universal 
limitation,  and  the  typical  way  in  which  it  is  solved. 

The  limitation  is  the  limited  nature  of  what  psycholo- 
gists call  "immediate"  or  "short-term  memory."  This 
limitation  is  overcome  by  the  use  of  some  kind  of  plan 
or  overview  of  the  complex  problem  or  program;  then  the 
problem  can  be  worked,  or  the  program  can  be  manipulated. 

A review  of  the  extent  of  the  limitation  on  immediate 
memory,  authored  by  a user  of  computers,  has  recently 
been  published.  (Simon,  1974) 
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There  has  been  much  theorizing  about  the  logical  organi- 
zations which  people  build  up  in  order  to  get  around  the 
limitation.  These  theories  have  generally  emphasized 
the  importance  of  models,  plans,  or  unifying  organiza- 
tions to  the  material  or  program  to  be  "exercised" 
mentally  by  the  worker.  The  basic  idea  is  that  the 
person  has  to  have  some  representation,  map,  or  plan 
which  he  can  use  in  developing  his  strategy  regarding 
the  problem.  One  theorist  called  this  special  kind  of 
plan  a "schema:" 

"'Schema'  refers  to  an  active  organisation  (sic)  of 
past  reactions,  or  of  past  experiences  which  must 
always  be  supposed  to  be  operating  in  any  well- 
adapted  organic  response.  That  is,  whenever  there 
is  any  order  or  regularity  of  behavior,  a particular 
response  is  possible  only  because  it  is  related  to 
other  similar  responses  which  have  been  serially 
organized,  yet  which  operate  not  simply  as  indi- 
vidual members  coming  one  after  another,  but  as  a 
unitary  mass.  Determination  by  schemata  is  the 
most  fundamental  of  all  the  ways  in  which  we  can  be 
influenced  by  reactions  and  experiences  which 
occurred  sometime  in  the  past.  All  incoming 
impulses  of  a certain  kind,  or  mode,  go  together  to 
build  up  an  active,  organised  setting:  visual, 

auditory,  various  types  of  cutaneous  impulses  and 
the  like,  at  a relatively  low  level;  all  the 
experiences  connected  by  a common  interest;  in 
sport,  in  literature,  history,  art,  science, 
philosophy,  and  so  on,  on  a higher  level." 

(Bartlett,  1962) 

These  "schemata"  may  be  organized  in  various  ways,  and 
the  natural  tendency  seems  to  be  (1)  to  prefer  a 
hierarchical  organization,  and  (2)  if  possible,  to 
impose  a hierarchical  organization  on  the  material  to 
be  remembered,  to  make  it  congruent  with  that  which  is 
easiest  for  people  to  work  with. 

A special  case  of  hierarchical  organization  is  G.A. 
Miller's  (1956)  "chunk."  According  to  Miller's  theory, 
a number  can  be  a "chunk"  of  information,  as  can  a word, 
or  a simple  visualized  design.  But  the  "chunk"  can  be 
organized  of  smaller  elements  with  which  a person 
happens  to  be  familiar,  and  these  smaller  elements  can 
themselves  contain  a great  deal  of  information.  For 
example,  one  can  remember  a telephone  number  of  seven 
decimal  digits  almost  as  easily  as  one  can  remember  a 
number  made  up  of  seven  binary  digits;  and  yet  the 
theoretical  information  in  the  seven  decimal  digits  is 
much  greater  than  that  in  the  seven-digit  binary  number. 


Clearly  this  natural  mode  of  thought  can  be  the  basis 
of  a hierarchy.  Consider,  for  example,  the  FORTRAN 
statement, 

IF (C  .EQ.  1.0)  GO  TO  20 

For  a person  just  learning  FORTRAN,  each  word  or  symbol, 
including  each  parenthesis,  might  be  a single  unit  of 
information.  For  an  experienced  programmer,  however,  a 
single  concept  could  be  represented  by 

IF  ( ) GO  TO  

which  represents  one  hierarchy  above  the  beginner's 
level . 

For  a person  who  was  somewhat  familiar  with  the  program, 
a single  "chunk"  (meaning,  in  effect,  "Test  for  'C'") 
would  be 

IF (C  .EQ.  1.0)  GO  TO  

Finally,  the  programmer  most  familiar  with  the  program 
might  think  of  the  test  and  its  consequence  in  " 20 " as 
only  one  "chunk"  of  information. 

According  to  theory  (e.g.,  Mandler,  1968),  a person  re- 
trieves information  from  his  own  mental  memory  in  terms 
of  such  chunks.  So,  the  larger  the  chunk  which  is  re- 
trieved (or  recalled) , the  more  potential  information 
it  contains. 

There  is  an  important  and  practical  corrollary  to  this 
kind  of  theory.  It  is  that  people  actually  think  faster 
when  problem  material  is  organized  in  terms  of  a 
hierarchy  with  which  they  are  familiar. 

Experimentation  with  words  and  English-language  concepts 
(but  not,  unfortunately,  with  programming  languages) 
indicates  that  this  corrollary  is  valid.  For  example, 
it  was  found  (Collins  & Quillian,  1969)  that  reaction 
times  were  longer  to  statements  mixing  high-level  and 
very- low- level  concepts;  and,  reactions  were  faster  to 
statements  made  up  of  concepts  at  adjacent  levels  on  a 
natural  hierarchy. 

(For  example,  reaction  times  for  statements  like  "A 
canary  has  wings"  were  longer  than  for  statements  like 
"A  bird  has  wings , " because  the  concept  of  wings  is  a 
part  of  the  general  "chunk"  of  birds;  it  is  not  unique 
to  canaries.  Consequently,  "wings"  is  stored  economi- 
cally with  the  concept  "birds,"  rather  than  with  the 
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subordinate  "canary."  Retrieving  "wings"  as  a property 
of  "canary"  requires  going  first  from  "canary"  to  the 
superordinate  "birds,"  and  then  to  "wings."  The  extra 
step  takes  extra  time. 

(On  the  other  hand,  "yellow"  is  part  of  the  "canary" 
concept,  and  people  can  rapidly  deal  with  the  statement, 
"A  canary  is  yellow. " It  requires  no  extra  steps  up 
and  down  natural  hierarchies . ) 

A much  older  study  (Bousfield  & Sedgewick,  1944)  showed 
that  people,  asked  to  give  continuous  associations  to 
a general  concept,  would  say  a burst  of  words,  pause, 
and  then  say  another  burst  of  associations.  For  example, 
if  the  general  category  was  "birds,"  a person  might 
first  say  "hawk,  eagle,  vulture,"  (wild  birds),  pause 
for  a few  seconds,  and  then  say  "chicken,  turkey,  duck" 
(domestic  birds) . Apparently  common  categories  are  also 
commonly  subdivided,  and  one  thinks  in  terms  of  one  sub- 
division until  one  happens  to  move  to  another  one. 

Another  study  (Tulving  & Pearlstone,  1966)  showed  that 
failure  to  recall  many  things  is  due  to  failure  to  "get 
into"  the  category  or  subdivision  in  which  the  things 
were  mentally  stored.  For  example  (referring  to  the 
previous  FORTRAN  example)  failure  to  recall  "C"  might  be 
caused  by  failure  to  recall  the  test  in  which  "C"  was 
used.  The  study  also  indicated  that  the  presence  of  a 
cue  may  be  necessary  to  moving  from  one  category  to 
another;  a reference  to  test  "X"  might  lead  to  the  re- 
call of  "C." 

Further  evidence  of  categorized  recall  is  provided  by 
analysis  of  the  common  "tip-of-the-tongue"  phenomenon. 
When  one  is  trying  to  recall  something  that  one  should 
know,  one  tends  to  recall  things  from  the  same  category, 
and  even  items  which  sound  like  the  unknown  item. 

(Brown  & McNeill,  1966)  Thus  it  has  been  proposed  that 
the  predilection  for  categorization  causes  people  to 
supplement  semantic  and  logical  categories  with 
phonetic  and  acoustic  ones.  (Bower,  1967) 

In  a previous  study  by  the  present  authors,  it  was  re- 
ported that  COBOL  programmers  make  practical  use  of 
physical  similarity.  In  COBOL,  a "paragraph"  may  be 
repeated,  almost  exactly,  several  places  in  a program. 

If  a maintenance  programmer  finds  three  or  four  lines 
which  he  does  not  understand,  he  may  look  around  to  see 
if  the  same  or  similar  lines  are  used  elsewhere.  There, 
in  a different  context,  he  may  be  able  to  understand  how 
they  function  as  a unit.  He  can  then  use  that  knowledge 
in  the  place  where  he  was  originally  puzzled. 
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3. 2. 2. 2 Predictions.  The  most  germane  findings  from 
such  studies  can  be  summarized  briefly: 

(1)  When  a person  has  to  recall  old  facts  related 
to  new  statements  (whether  program  statements 
or  otherwise) , he  often  seems  to  use  a set  of 
categories  in  the  recall  process;  and  the 
categories  are  often  arranged  hierarchically. 

(2)  People  tend  to  use  their  own, "natural"  category 
system,  but  they  will  also  accept  and  use  cate- 
gories imposed  by  the  people  giving  them 
directions.  (Wortman  & Greenberg,  1971; 

Tulving  & Pearlstone,  1966)  In  either  case, 
hierarchical  category  formation  is  an  economi- 
cal "plan"  for  storage  and  retrieval  of  in- 
formation, and  it  may  be  a necessary  condition 
for  "keeping  in  mind"  a large  set  of  related 
statements.  (Miller,  1956;  Mandler,  1968) 

(3)  The  superordinate/subordinate  relationship  is 
not  the  only  possible  basis  for  categorization. 
Many  other  organizational  schemes  may  be  fitted 
to  a hierarchical  plan.  These  range  from 
acoustic  similarity  (Bower,  1967)  to  the  mental 
treatment  of  a few  lines  of  code  as  falling  in 
the  same  functional  class  as  similar  lines 
elsewhere. 

In  other  words,  thinking  man  apparently  has  a predi- 
lection for  hierarchical  structures  for  storing  and  re- 
trieving concepts,  which  are  in  turn  defined  by  various 
categories.  This  may  be  the  only  way  people  can  handle 
large  amounts  of  information  or  large  numbers  of  state- 
ments at  a time. 

Given  this  theoretical  background,  the  following  pre- 
dictions are  a logical  conclusion: 

(1)  Highly  modular  programs  are  more  congruent  with 
the  human  predilection  for  hierarchical  and 
categorical  memory  structures  than  are  programs 
of  low  modularity;  therefore  the  modular  pro- 
grams should  be  easier  to  maintain. 

(2)  Programs  of  low  per-unit  complexity  should  also 
be  easier  to  deal  with  categorically,  and  they 
should  be  intrinsically  easier  to  maintain. 

(3)  The  advantage  of  modular  programs  should  in- 
crease with  the  complexity  of  the  program. 
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In  other  words,  modularity  should  help  the  maintenance 
programmer  to  keep  relevant  aspects  of  some  one  else's 
program  in  mind.  Perhaps  more  important,  it  should  also 
provide  him  with  a sort  of  "index"  to  the  program,  to 
help  him  focus  down  on  the  points  at  which  code  must 
ultimately  be  laid. 

The  universality  of  hierarchical  and  other  categori- 
zations of  concepts,  illustrated  in  a variety  of  experi- 
ments of  the  type  cited  here,  indicates  that  people  have 
a strong  bias  for  using  this  kind  of  "plan."  (The  bias 
may  be  innate , or  it  may  be  due  to  the  kind  of  edu- 
cation and  experience  that  people  normally  receive.  But 
its  origin  is  not  germane  here,  as  long  as  the  bias 
exists.)  People,  including  programmers,  function  best 
when  the  material  they  have  to  work  with  fits  their 
biases,  habits,  and  cognitive  approaches  to  the  world. 

A computer  program  organized  in  a quasi-hierarchical 
fashion,  or  one  with  distinct  and  realistic  categories 
such  as  modules,  should  be  easier  to  comprehend,  accord- 
ing to  the  theory,  than  one  not  so  organized. 


3.2.3  Modularity  Recommendation 

Perhaps  the  most  important  divergence  between  the 
theoretical  predictions  and  the  actual  results  concerns 
the  effect  of  "high  modularity"  in  interaction  with 
"complexity."  According  to  the  theory,  modularity  should 
be  of  greatest  help  in  connection  with  the  greatest 
degree  of  per-unit  complexity.  In  actuality,  this 
difference  did  not  appear. 

In  the  opinion  of  the  present  authors,  this  divergence 
probably  stems  from  the  fact  that  the  experimental 
design  permitted  only  two  degrees  of  modularity:  "high" 

and  "low."  In  particular,  "high"  was  probably  not  high 
enough  to  allow  the  effects  to  appear. 

This  opinion  is  based  in  part  upon  the  results  of  a 
previous  study  (Overton  et  al.,  1973)  in  which  modu- 
larity was  also  an  independent  variable;  but  in  which  it 
was  found  that  the  experimental  programmers  preferred  a 
higher  degree  of  modularity  than  any  which  was  actually 
represented  in  the  study.  (Smaller  modules  and  sub- 
modules  represent  a higher  degree  of  modularity.) 

It  is  also  based  on  the  academic  literature  regarding 
problem-solving.  While  the  artificial  problem-solving 
studies  may  not  be  entirely  applicable  to  maintenance 
programming,  they  do  show  that,  for  most  of  the  cate- 
gories of  statements  with  which  people  actually  work, 
the  category  size  is  rather  small. 


37 


Most  importantly,  however,  the  authors  cite  the  "Studies 
in  Conceptual  Groupings"  described  later  in  this  report. 
(Previous,  similar  studies  are  also  relevant.)  In  the 
studies  covered  here,  maintenance  programmers  were 
helped  quite  significantly  by  automated  displays  of 
groupings  of  typ^s  which  programmers  tended  to  deal 
with  as  units.  And  the  modal  sizes  of  the  helpful 
groupings  fell  in  a range  of  approximately  six  to  eleven 
statements.  These  are,  of  course,  much  smaller  than 
what  would  normally  be  defined  as  the  smallest  module 
in  a large  software  system. 

An  incidental  implication  of  the  present  studies  relates 
to  the  question  of  the  maximum  number  of  programmers  who 
should  be  assigned  to  the  development  of  a module. 

(While  the  present  studies  are  focused  on  maintenance, 
many  of  the  lessons  probably  apply  to  development.) 

After  citing  other  recommendations  of  a maximum  of  about 
ten  programmers  to  a module,  one  author  (Simmons,  1972) 
declares  that  his  review  indicates  that  the  number 
should  be  a maximum  of  six  people. 

The  opinion  of  the  present  authors  is  more  extreme.  In 
view  of  the  lessons  learned  in  these  volumes,  modules 
should  probably  be  broken  down,  in  the  planning  phase, 
to  sub-modules  so  small  that  the  maximum  number  of  pro- 
grammers assigned  to  each  is  one . 


3. 3 Other  Experimental  Results 


A number  of  other  conclusions  can  be  drawn  from  the 
notes  and  data  from  the  Terminal  Arrangements  activities. 
These  include  the  following: 

(1)  The  summed  effect  of  small  distractions  may  be 
greater  than  most  people  have  suspected. 

(2)  The  programmer  is  more  likely  to  make  mistakes 
when  he  "shifts  gears"  and  goes  from  one  level 
of  discourse  to  another. 

(3)  Appropriate  visual  analogs  of  digital  displays 
might  facilitate  people's  maintenance  work. 

(4)  Programmers  often  ignore  their  terminals, 
during  or  at  the  end  of  a session,  for  con- 
siderable lengths  of  time.  These  lapses  may 
indicate  that  the  terminal  environment  is  not 
conducive  to  some  necessary  kinds  of  thinking. 

(5)  Allocation  of  tasks  between  the  programmer  and 
the  operating  system  could  be  improved  by 
having  the  system  perform  even  more  identi- 
fication and  clerical  support  functions. 

(6)  For  information  to  support  his  work,  the 
maintenance  programmer  at  a graphics  console 
calls  on  an  impressive  variety  of  sources  of 
information. 

(7)  Sometimes  a program  module  must  be  analyzed  as 
a whole  but,  because  of  its  size  or  other 
problems , it  cannot  be  displayed  as  a whole  at 
the  terminal. 

(8)  Several  other  points  can  be  made.  These  include 
the  possibilities  that  (a)  characteristic  turn- 
around time,  or  system  response  time,  in- 
fluences the  type  of  errors  which  the 
programmer  characteristically  makes;  and 

(b)  different  human  senses  interact  in  ways 
which  may  be  significant. 

Potentially,  all  of  these  findings  have  practical  impli- 
cations; but  some  will  be  easier  to  implement  than 
others . 

The  above  items  are  discussed  in  greater  detail  below. 
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3.3.1  Distractions 


System  designers  seem  to  have  a tendency  to  want  to 
display  everything  which  a programmer  might  ever  want 
to  see  on  a graphics  terminal.  This  tendency  is  under- 
standable in  absence  of  definite  specifications  regard- 
ing what  he  will  need  to  see.  But  it  may  constitute  a 
source  of  distractions , and  there  are  indications  that 
distractions  in  general  are  a very  definite  handicap  to 
the  maintenance  programmer. 

Of  course  distractions  can  come  from  many  sources. 
External  noises  and  sights  are  the  most  obvious.  But 
they  can  come  from  the  very  activities  which  the 
graphics  system  requires  the  maintenance  programmer  to 
perform.  In  one  case,  the  programmer  was  checking  the 
functioning  of  a change,  and  he  was  required  to  re- 
submit accounting-type  information  before  making  the 
"check-out  run."  But  apparently  this  information  re- 
minded him  of  costs,  which  in  turn  reminded  him  of  a 
core  utilization  problem,  which  caused  him  to  forget  the 
exact  points  he  needed  to  check  in  the  run  he  was 
starting  to  make. 

Displays  which  were  not  under  the  programmers'  control, 
such  as  lengthy  displays  inserted  by  analysts  for  the 
possible  monitoring  of  the  operating  system,  seemed 
particularly  distracting. 

According  to  Dr.  John  Goodenough  (in  a personal  communi- 
cation in  connection  with  an  earlier  project) , mainte- 
nance programming  is  more  difficult  and  more  "subtle" 
than  development  programming;  the  maintainer  must  worry 
about  more  indirect  problem  areas,  with  which  he  is  less 
familiar,  than  the  developer.  Accordingly,  he  is  more 
vulnerable  to  disruption  when  he  is  in  the  midst  of  an 
analysis  of  a program  section  which  may  seem  "tricky" 
to  him. 

Analyses  have  starting  points;  and,  in  programming, 
these  are  often  displays.  In  the  words  of  an  older  dis- 
cussion of  problem-solving,  "Trains  of  thought  are 
pulled  by  stimuli."  (Overton,  1959)  Paraphrasing  those 
words,  delicate  trains  of  thought  can  also  be  derailed 
by  irrelevant  stimuli. 

When  the  effect  is  measured  carefully,  even  very  small 
visual  displays  can  have  a significant  effect  on  work. 
Inspired  by  the  theory  that  one  adapts  in  almost  a 
physical  sense  to  what  one  is  observing,  a test  was  made 
of  the  effect  of  a single,  irrelevant  flash  of  light. 
(Helson  & Steger,  1962)  The  test  showed  that  it  retarded 


human  performance.  Later  experimentation  (Vruels  & 
Schmidt,  1966)  verified  the  effect  and  suggested  a 
reason:  "The  visual  system  seems  to  act  like  a circuit 

with  two  or  more  integrators  in  series,  but  with  a by- 
pass loop  that  allows  a partially  unprocessed  signal  to 
modify  slightly  the  already  processed  signal  in  a 
comparator."  In  other  words,  the  irrelevant  signal  may 
cause  the  first  one  to  be  distorted  while  it  is, 
figuratively  speaking,  en  route  to  mental  processing. 

Because  of  the  complexity  of  the  process  of  maintenance 
programming,  it  was  not  possible  to  obtain  accurate 
measurements  of  the  times  that  programmers  were  dis- 
tracted, or  the  seriousness  of  these  distractions.  The 
programmers  themselves  probably  would  not  know.  One  can 
be  distracted  without  being  aware  of  the  effects  or 
extent  of  the  distraction.  (Also,  it  would  distract  you 
to  ask  you  if  you  were  distracted!)  In  spite  of  the 
lack  of  objective  data,  however,  the  authors  developed 
the  strong  opinion — which  is  reinforced  by  the  limited 
but  relevant  experimentation  of  the  type  cited  above — 
that  the  summed  effect  of  small  distractions  in  mainte- 
nance programming  would  be  a surprisingly  great  waste 
of  programmers'  time. 


3.3.2  Level  Shifts 

Many  small  phenomena,  like  blinking  one's  eyes  while 
reading,  are  frequent  but  not  conspicuous.  When  these 
phenomena  affect  one's  work,  however,  their  cumulative 
effect  may  be  considerable.  An  example  are  the  phenomena 
associated  with  shifting  between  "levels  of  discourse" 
(i.e.,  levels  of  description  of  a program,  mode  or 
language  of  statement  of  the  program,  etc.)  in  mainte- 
nance work. 

It  should  be  emphasized  that  some  such  shifts  are 
necessary.  The  dissertation  of  Brooks  (1974)  cites  evi- 
dence behind  the  theory  that  programmers  necessarily  and 
frequently  shift  up  and  down  between  "planning"  (on  a 
small  scale)  and  coding.  (In  a personal  communication. 
Brooks  also  cited  a spontaneous  experiment  with  Prof. 
Djikstra,  who  is  generally  thought  to  be  a firm  advocate 
of  top-down  programming.  Brooks  said  that  when 
Djikstra' s programming  was  analyzed  by  Brooks'  system, 
Djikstra  also  was  found  to  move  up  and  down  frequently 
between  leve Is.) 

The  effects  of  shifts,  even  at  the  same  level,  are  de- 
tectable. It  has  been  found  that  even  when  a person 
knows  two  languages  well,  his  work  is  slightly  delayed 
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every  time  he  shifts  between  them.  (Kolers,  1973)  This 
effect  was  found  with  natural  languages,  but  it  probably 
applies  to  programming  languages  as  well. 

In  this  experimentation,  mistakes  by  the  maintenance 
programmer  often  seemed  to  accompany  shifts  between 
levels  of  description.  Errors  were  made  in  the  detailed 
formats  of  input  data  when  the  programmer  had  just  been 
worrying  about  the  higher-level  logic  of  the  program. 

Or,  engrossed  in  the  logic  of  a routine,  he  fails  to 
push  a button  and  ask  for  a copy,  to  use  in  later 
higher-level  analysis,  of  the  graph  the  routine  is  pro- 
ducing. Or,  thinking  of  the  files  which  a program  does 
and  does  not  use,  the  programmer  recalls  that  data  need 
to  be  changed  in  one  of  them;  he  tediously  changes  the 
data,  then  returns  to  thinking  of  the  program  functions 
and  realizes  that  the  program  does  not  use  that  particu- 
lar file! 

Asked  about  this  kind  of  error,  one  programmer  explained: 
"Well,  it's  like  shifting  gears.  You're  more  likely  to 
goof  when  you  have  to  shift  gears." 

The  implication  of  all  of  this  is  obvious  although  per- 
haps difficult  to  implement:  The  procedures  for  mainte- 

nance programming  at  terminals  should  discourage  unneces- 
sary shifting  up  and  down  between  levels  of  discourse. 


3.3.3  Visual  Analogs 

The  term  "visual  analog"  is  used  here  to  denote  a graphic 
(analog-type)  representation  of  digital  data.  For 
example,  the  columns  projecting  from  the  quadrant  in 
Figure  4 are  analogs  of  the  numbers,  giving  productive 
times  under  four  conditions,  in  Figure  3a. 

Often  visual  analogs  are  not  generated  for  one  simple 
reason:  They  cost  more  than  digital  displays.  Even  the 

simple  drawing  in  Figure  4,  for  example,  requires  much 
more  work  than  would  be  needed  to  simply  write  down  the 
numbers.  But  the  advantages  may  be  significant. 

In  these  studies,  the  programmers  at  graphics  terminals 
consistently  used  visual  analogs  for  at  least  one  kind 
of  test  of  the  acceptability  of  modifications.  When  the 
programs  were  designed  to  draw  graphs  for  engineers,  a 
modification  would  rarely  be  tested  in  terms  of  the  data 
files  it  created  or  the  equations  it  used;  instead,  the 
programmer  would  have  the  modified  program  draw  a new 
graph,  and  he  would  look  at  it  and  ask  either  himself  or 
an  engineer  or  both:  "Does  that  look  reasonable?" 
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Figure  4 . Visual  Analog  of  Productive  Times  Data 


43 


In  general  it  seems  that  when  visual  analogs  can  be  pro- 
duced for  "reasonableness  checks,"  the  analogs  indeed 
provide  an  efficient  way  for  people  to  make  these  checks. 

Visual  analogs  may  be  appropriate  for  purposes  other 
than  the  making  of  gross  tests  of  program  functioning. 

For  example,  it  has  been  shown  that  people  are  less 
likely  to  make  gross  errors,  and  are  more  likely  to 
remember  what  they  see,  if  they  are  shown  pictorial 
displays  rather  than  numerical  arrays  of  a certain  de- 
gree of  complexity.  (Newman,  1966) 

Appropriateness  of  displays  will  also  be  determined  by 
the  people  for  whom  they  were  intended.  For  example, 
it  was  found  that  two  dozen  English  housewives  performed 
a decision-making  task  better  when  the  data  needed  to 
make  the  decisions  were  expressed  in  terms  of  rods  of 
differing  length,  rather  than  in  terms  of  numbers. 
(Hammerton,  1973)  Whether  college  mathematics  majors 
would  have  done  better  under  these  same  conditions  is 
not  known.  However,  it  was  found  that  in  a simpler 
job — simply  reacting  to  the  differences  between  pairs 
of  numbers — college  students  reacted  more  quickly  when 
the  quantities  were  presented  in  analog  form  than  when 
they  were  presented  digitally.  (Moyer  & Landauer,  1967) 

In  brief,  it  is  safe  to  say  that  there  is  a natural 
tendency,  which  may  be  overcome  to  some  extent  by  edu- 
cation, for  people  to  work  more  easily  with  visual 
analogs . 

The  maintenance  programmers  used  another  technique  which 
was  related  to  visual  analogs.  When  they  were  puzzled, 
or  otherwise  under  stress,  they  tended  to  simplify  the 
picture  before  them.  When  a graphics  package  did  not 
seem  to  be  working  properly,  the  programmer  projected 
the  normally  three-dimensional  view  (generated  by  the 
program)  into  a two-dimensional  view  (also  generated  by 
the  program) . Apparently  he  felt  that  he  could  "get 
started  better"  in  understanding  the  problem  with  the 
simpler  view.  Similarly,  data-processing  routines  for 
dealing  with  many  variables  were  "compressed"  by 
maintenance  programmers  so  that  the  routines  operated 
on,  and  displayed  results  from,  only  a few  variables  at 
a time.  To  deal  with  a complex  problem,  the  programmers 
clearly  preferred  to  start  with  a simple  picture  (both 
figuratively  and  literally)  and  work  up  to  a complex 
picture,  rather  than  vice  versa. 

It  seems,  then,  that  the  natural  preference  for  visual 
analogs  should  be  exploited,  rather  than  fought,  wherever 
it  is  feasible  to  do  so  in  maintenance  programming.  Two 
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feasible  areas  are  probably  the  making  of  reasonableness 
checks,  and  the  simplification  of  complex  pictures  as 
starting  points  for  debugging. 


3.3.4  Avoiding  the  Terminal 

At  one  time  during  one  experimental  session,  one  highly- 
educated  programmer  said,  "Let's  go  back  to  the  listing 
to  get  our  bearings."  He  then  ignored  the  terminal 
while  he  studied  the  use  of  large  data  sets.  Other  pro- 
grammers similarly  avoided  the  terminal  while  trying  to 
work  out  some  kinds  of  problems . 

This  kind  of  behavior  has  been  statistically  verified 
elsewhere.  Empirical  data  were  collected  on  the  times 
of  terminal  use  in  an  interactive  system  (Boies,  1973) , 
and  a principal  finding  was  that  it  was  common  for  pro- 
grammers to  be  " . . . leaving  their  terminals  for  rela- 
tively long  periods  of  time  . . . often  (returning)  only 
to  sign  off  . . . . " The  interpretation  the  present 
authors  make  of  this  finding  is  that  maintenance  pro- 
grammers often  try  to  work  something  out  without  using 
the  terminal;  and  if  they  do  not  succeed  in  a reasonable 
time,  they  sign  off  and  go  to  a desk  to  try  some  more. 

Another  part  of  the  empirical  study  (Boies,  1973)  re- 
ported that  when  the  system  detected  an  error  in  FORTRAN, 
" . . . a diagnostic  message  and  the  offending  line  were 
displayed  on  the  terminal  and  the  user  was  given  a prompt 
to  correct  the  error.  In  the  26  programs  in  which  this 
occurred,  only  once  did  the  user  correct  the  errors  in 
the  program. " (Underlining  was  added  by  the  present 
authors;  we  would  also  have  put  an  explanation  mark  at 
the  end  of  the  sentence.) 

Why  did  the  programmers  not  correct  the  errors  when  the 
system  pointed  them  out?  In  some  cases,  apparently, 
they  tried  to:  "...  six  times  the  system  crashed  or 

the  user  session  ended  while  . . . waiting  ...  to 
correct  the  program."  In  some  cases,  in  other  words, 
it  was  not  easy  to  make  the  corrections  at  the  terminal 
at  that  moment. 

The  most  frequent  case,  however,  was  for  the  person  to 
request  the  system  to  continue  without  the  error  being 
corrected.  Here  the  programmer  evidently  wanted  to 
pursue  one  train  of  thought  at  the  terminal,  and  to 
worry  about  the  error  at  a different  time. 

This  behavior  seems  to  contradict  somewhat  the  claim, 
made  by  some  proponents  of  time-sharing  systems,  that  the 
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graphics  terminal  is  an  aid  to  the  programmer's 
thinking.  But  the  picture  is  probably  not  that  simple. 
What  seems  to  be  happening  is  this:  The  terminal  is  an 

aid  to  some  kinds  of  thinking;  so  the  experienced  pro- 
grammer tends  to  do  those  kinds  at  the  terminal;  but 
when  he  needs  to  do  another  kind,  he  avoids  the  terminal, 
and  he  looks  at  different  things. 

These  tendencies  have  practical  implications  which  will 
be  discussed  in  Section  4 under  General  Interpretations 
and  elsewhere  in  this  report. 


3.3.5  Task  Allocation 

In  batch  processing,  it  is  customary  to  have  the  operating 
system  write  some  identification  on  a job  when  it  is  run. 
Of  course  the  user  has  to  give  his  name,  etc.,  but  the 
software  can  add  the  date  of  the  run  and  useful  but  non- 
unique data  such  as  compile  time  and  execution  time. 

This  custom  is  an  example  of  the  result  of  a process 
which,  when  done  formally,  is  called  "task  allocation": 
allocation  of  tasks  to  be  performed  by  the  programmer 
versus  those  to  be  performed  by  the  computer. 

Task  allocation  is  often  not  done  formally,  and  the  in- 
formal results  vary  from  system  to  system  and  from  in- 
stallation to  installation.  Because  time-sharing 
systems  are  newer  than  batch,  there  is  probably  even 
more  variation  from  system  to  system  with  graphics 
consoles  than  there  is  with  batch  operations.  Because 
of  this  variation,  observations  made  at  one  installation 
may  not  be  valid  in  other  "shops."  In  any  case,  some 
observations  on  task  analysis  were  made  during  the 
Terminal  Arrangements  studies. 

Of  course  one  always  wants  to  assign  the  "dog  work"  to 
the  computer.  But  this  has  not  always  been  done.  Dis- 
play identification  is  one  area  in  which  improvements 
might  be  made. 

In  one  case,  a programmer  was  working  at  a terminal  with 
listings  of  two  different  compilations  of  a program.  He 
slipped  back  and  forth  among  the  fan-fold  sheets,  mixing 
them  up  as  he  tried  to  study  them  in  relation  to  the 
displays  on  the  screens.  But  the  listings  were  identi- 
fied only  on  the  top  sheet  of  each;  and,  in  the  middle, 
the  programmer  became  confused.  For  maintenance  work, 
a simple  identifier  on  every  fan-fold  sheet  might  be 
worth  while. 
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In  a more  general  case,  the  system  generated  a graphics 
display,  and  the  programmer  wanted  a copy  of  it  for 
future  references.  He  could  get  the  copy,  but  then  he 
had  to  identify  it  by  hand.  An  easy,  semi-automatic 
notation  of  identifying  data — especially,  parameters 
being  changed  from  one  "picture"  to  another — would  ease 
the  programmer's  job. 

After  identifying  himself,  the  programmer  should  stay 
identified  as  long  as  he  is  at  a terminal.  On  one 
system,  his  identity  is  keyed  to  the  application  pro- 
gram with  which  he  is  working,  and  he  has  to  re-submit 
his  identity  if  he  calls  in  another  program  such  as  a 
library  routine.  There  are  other  examples  of  systems 
which  do  not  support  the  programmer  well  in  handling 
clerical  and  bookkeeping  data. 

Finally,  options  (regarding  display  parameters,  compu- 
tation mode  choices,  etc.)  should  be  treated  differently 
when  a programmer  is  doing  a series  of  tests  on  a pro- 
gram. Instead  of  having  to  make  all  of  the  choices 
(like  a user  using  the  program  for  the  first  time) , he 
should  be  able  to  say,  in  effect,  "Now  change  only 
option  X;  make  it  B. " This  would  permit  easier  and 
faster  comparisons;  and,  probably,  better  deductions 
from  the  series. 


3.3.6  Sources  of  Information 

When  terminal-oriented  systems  were  originally  being 
developed,  news  releases  spoke  of  glowing  promises. 
Seated  at  his  terminal,  each  of  many  people  could  have 
easy  access  to  tremendous  computing  power  and  to 
valuable  banks  of  public  information. 

This  remains  a worthy  goal.  But  for  the  maintenance 
programmer,  at  least,  the  picture  of  him  wed  to  his 
terminal,  with  the  two  of  them  overcoming  all  bugs  and 
modifications,  is  a picture  which  is  strikingly  in- 
complete . 

The  fact  is,  that  to  support  his  work,  the  present-day 
maintenance  programmer  calls  on  an  impressive  variety 
of  sources  of  information. 

(1)  The  news-release  picture  is  accurate  to  the 
extent  that  the  one  most  frequently  tapped 
source  of  information  is  probably  the 
terminal . 
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(2) 


In  almost  every  case,  however,  the  programmer 
comes  to  the  terminal  with  a marked-up 
print-out,  usually  a program  listing,  as  a 
guide  to  at  least  his  first  actions.  If  he 
seems  to  "get  stuck"  in  maintenance,  and  if 
the  paging  and  other  display  routines  available 
on  the  terminal  do  not  satisfy  him,  he  may 
spend  most  of  his  time  studying  the  print-out. 

In  some  installations,  the  programmer  had 
trouble  finding  a place  to  lay  out  all  of  his 
listings. 

(3)  Depending  on  exactly  who  is  involved  and 
available,  he  may  telephone  or  otherwise  talk 
to  another  programmer . Often  this  is  not  the 
original  developer  of  the  program,  but  rather 
another  maintenance  programmer  who  has  worked 
on  it  recently. 

It  was  interesting  to  note  that  the  type  of 
question  asked  of  the  other  programmer  was 
almost  always  at  either  a high  level  of  dis- 
course (e.g.,  concerning  the  purpose  of  a 
graph  for  an  engineer,  or  other  conditions  re- 
garding the  use  of  the  program)  or  a very  low 
level  of  discourse  (e.g.,  concerning  the 
purpose  of  a single  symbol) . Questions  of 
intermediate  level,  such  as  the  exact  function 
served  by  a short  section  of  code,  were  rarely 
asked. 

(4)  The  maintenance  programmer  sometimes  turned  to 
the  program  manuals  for  information.  But  this 
was  relatively  rare. 

(5)  At  vector  (or  picture-drawing)  graphics  termi- 
nals, the  terminal  is  supplemented  by  a photo- 
copy machine,  which  takes  a "hard"  picture  of 
what  is  on  the  "tube."  The  programmer  inter- 
acts with  this  machine  by  telling  it  when  to 
make  a hard  copy. 

(6)  Old  copies  from  the  machine  form  a much  more 
important  source  of  information  for  the  mainte- 
nance programmer.  He  uses  them  to  compare 
"before"  and  "after"  computational  results,  to 
see  if  he  has  made  progress. 

At  no  installation  was  there  a formal  assignment 
' of  a place  for  the  programmer  to  store  these 
copies  temporarily.  He  usually  just  laid  them 
on  top  of  the  photocopy  machine.  In  one  case. 
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.Figure  5.  Terminal  Arrangements 
Sources  of  Information  : 


he  scotch-taped  two  of  them  to  the  edges  of  the 
graphics  terminal. 

(7)  The  engineer  for  whom  the  program  was  being 
modified,  or,  more  generally,  the  programmer's 
customer  was  occasionally  available  to  the 
maintenance  programmer.  From  him,  the  pro- 
grammer got  information  about  the  acceptability 
and  reasonableness  of  tentative  computational 
results . 

(8)  Distractions  abounded,  especially  in  the 
larger  installations". 

No  one  in  the  field  should  be  surprised  that  the  mainte- 
nance programmer  at  a terminal  uses  these  and  other 
sources  of  information.  In  planning  the  physical  arrange- 
ments around  a new  terminal,  however,  a little  more 
thought  should  be  given  to  the  fact  that  he  will  use 
them. 


3.3.7  Module  Displays 

When  programmers  turned  away  from  the  terminal  and  to  a 
print-out,  they  normally  spread  out  more  than  one  page 
of  paper;  they  seemed  to  be  studying  a large  section  of 
coding. 

This  behavior  helps  indicate  the  existence  of  a rather 
obvious  problem:  As  a rule,  a module  needs,  simply  be- 

cause of  "the  nature  of  the  beast,"  to  be  analyzed  as  a 
whole.  But  sometimes  the  module  is  too  long  to  be  dis- 
played all  at  once,  in  readable  form,  on  the  terminal. 
Also,  deficiencies  in  the  system's  paging  and  indexing 
routines  can  prevent  some  modules  from  being  displayed 
as  a whole. 

In  these  cases,  the  maintenance  programmer  can  turn  to 
the  corresponding  hard  copy,  if  it  is  available,  and 
study  it.  Otherwise,  he  must  try  to  use  his  memory  or 
make  spur-of-the-moment  notes  to  supplement  the  display. 
In  any  case,  he  is  using  his  own  papers  or  memories  to 
supplement  the  system. 


3.3.8  Other  Points 

Miscellaneous  points  from  the  experimental  sessions  in- 
clude the  following: 

(1)  When  system  response  through  the  terminal  was 
rapid,  two  of  the  programmers  (who  knew  they 


50 


were  being  observed)  tended  to  repeat  the  same 
kind  of  error  in  quick  succession. 

The  reason  for  this  perseveration  of  errors  may 
be  that  the  programmers  felt  pressures.  (As 
previously  reported,  new  people  at  terminals 
often  feel  as  though  they  are  "in  a race  with 
the  computer."  And  being  under  observation  may 
bother  some  people.)  It  is  an  established 
principle  that  too  much  pressure  tends  to  dis- 
rupt complex  problem-solving,  even  though  it 
may  encourage  simple,  repetitive  work.  (Over- 
ton,  1959)  (In  the  extreme,  it  would  do  no 
good  for  a dictator  to  order  his  subjects  to 
"Be  intelligent!"  or  "Be  creative!")  Because 
of  this  principle,  some  of  the  avoidance  of 
the  terminal  cited  above  may  be  necessary.  Or, 
programmers  should  not  overestimate  the  cost 
pressures  in  terminal  usage. 

(2)  Addition  of  sound  to  sight  can  result  in  some 
tricky  mixtures.  For  example,  it  has  been 
shown  that  if  people  see  a series  of  numbers, 
they  can  remember  better  the  order  in  which 
the  numbers  were  presented.  But  if  they  hear 
the  same  series  (over  the  same  span  of  time) , 
they  can  recall  the  exact  numbers  better,  but 
they  are  more  likely  to  get  the  order  of 
presentation  wrong.  (Briggs,  1973) 

If  the  object  is  to  make  a person  remember  some- 
thing, this  is  best  accomplished  by  requiring 
him  to  recode  it  to  another  sense — for  example, 
by  presenting  visual  symbols  to  him  and  having 
him  repeat  them  orally.  Often  in  maintenance, 
however,  the  burden  of  remembering  something 
like  a specific  real  number  should  not  be  given 
to  the  programmer  in  the  first  place;  scratch- 
pad memory  or  a good  editor  would  be  a better 
tool. 

As  another  example  of  an  odd  effect,  it  has 
been  found  that  people  see  less  on  the  side  of 
their  visual  field  which  is  opposite  from  an 
irrelevant  noise.  (Nice,  1973) 

When  the  vibration  of  noise  includes  fre- 
quencies in  the  range  of  about  10  to  30  Hz,  it 
is  in  the  range  which  most  degrades  visual 
acuity.  (Semple  et  al.,  1971) 
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In  brief,  there  are  conditions  in  which  the 
freedom  from  extraneous  noise  could  be  more 
than  an  esthetic  goal,  but  in  which  it  could 
somewhat  improve  the  programmers'  efficiency. 

(3)  In  general,  more  emphasis  needs  to  be  placed 
on  the  question  of  what  displays  maintenance 
programmers  need  to  see  together,  for  purposes 
of  comparison. 

Some  examples  of  this  need  are  trivial : A 

programmer  wanted  to  compare  a print-out  with 
the  terminal,  but  he  did  not  have  a big  enough 
flat  surface  around  the  terminal  on  which  to 
place  the  print-out.  Or,  he  needed  to  compare 
drawings  made  with  different  scalings  and  other 
parameters,  and  he  had  to  scotch-tape  old 
copies  to  the  sides  of  the  graphics  terminal. 

Others  are  more  basic:  In  a previous  project 

which  included  a study  of  "split  screens"  on 
terminals,  programmers  working  with  highly 
modularized  programs  were  found  to  be  most 
likely  to  elect  to  use  the  split-screen  feature. 
Apparently  the  reason  was  that  they  wanted  to 
compare  different  versions  of  the  same  module, 
or  a module  and  its  resulting  file. 

In  any  case,. much  of  maintenance  involves 
comparisons,  and  systems  should  be  designed  to 
facilitate  those  comparisons  which  are  most 
likely  to  be  made. 

(4)  The  period  of  time  in  which  a person  can  con- 
centrate on  intellectual  work  may  be  limited. 

No  programmer  scheduled  himself  for  more  than 
an  hour  of  actual  maintenance  work  on  a termi- 
nal. On  the  other  hand,  more  routine  work  was 
done  for  longer  periods  without  breaks. 

A brief  survey  of  a related  problem  is  pro- 
vided by  Broadbent  (1971) . Discussing  research 
on  people  watching  aircraft  radars,  he  notes 
that  errors  rose  significantly  "...  after 
. . . only  half  an  hour;  which  was  a remarkably 
rapid  onset  of  'fatigue. ' A deterioration  of 
this  sort  has  been  found  in  large  numbers  of 
similar  tasks  since  the  original  investigation 
....  It  is  of  course  of  some  practical 
importance  . . . . " (p.  19) 
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As  in  other  cases,  freedom  may  be  the  best 
policy:  Allowing  the  programmer  to  pace  him- 

self according  to  the  nature  of  the  problem 
before  him  may  minimize  errors. 
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4.  INTERPRETATIONS  AND  RECOMMENDATIONS 


4. 1 General  Interpretations 

Many  programmers  do  not  like  maintenance  work;  it  is 
just  one  problem  after  another.  At  best,  you  (the 
maintenance  programmer)  face  the  problem  of  poring 
through  a problem  to  find  the  right  places  to  make  a 
modification  . . . complicated  by  the  problem  of  in- 
suring that  your  modification  does  not  "foul  up"  some 
other  obscure  part  of  the  system.  At  worst,  you  have  to 
correct  someone  else's  failure  ...  to  track  down  a bug 
whose  creator  was  not  aware  of  creating  it. 

Problems  can  be  cast  in  ways  which  make  them  easier  to 
overcome.  However,  much  prior  study  of  the  problems  is 
necessary  before  better  "casting"  can  actually  be 
accomplished.  From  one  point  of  view,  the  Terminal 
Arrangements  studies  are  concerned  with  casting  the 
problems  of  maintenance  in  a form  which  is  less 
offensive  to,  and  difficult  for,  programmers. 

(The  studies  in  Conceptual  Groupings  can  be  viewed  in 
the  same  light,  although  they  are  concentrated  more  on 
determining  the  feasibility  and  value  of  a single  set  of 
techniques . ) 

Casting  programs  in  modular  form,  the  Terminal  Arrange- 
ments study  found,  seems  to  make  maintenance  problems 
more  tractable.  The  more  complicated  the  program  area, 
the  greater  the  degree  of  modularization  which  may  be 
necessary  to  help  the  programmer. 

In  general  (going  beyond  modularization)  there  is 
probably  a powerful  and  important  interaction  between 
(1)  the  intrinsic  nature  and  complexity  of  a problem, 
and  (2)  the  modes  in  which  it  is  best  stated  and  ana- 
lyzed. 

For  example,  no  college  professor  of  mathematics  would 
attempt  to  present  a complex  equation  by  reading  it  in 
a one-dimensional  stream  of  words  and  letters.  Instead, 
he  would  write  it  on  a blackboard,  where  students  could 
look  at  it,  read  it  back  and  forth,  and  study  symbols 
from  top  to  bottom  if  necessary.  In  other  words,  a 
writing  surface  is  better  for  presenting  equations  than 
is  a stream  of  spoken  words. 
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In  terms  of  the  design  of  arrangements  for  terminals, 
the  point  of  the  little  story  of  the  mathematics  pro- 
fessor is  this:  The  blackboard  is  a form  of  memory , and 

it  is  quite  analagous  to  a computer  memory.  The  pro- 
fessor  uses  the  blackboard  to  supplement  human  memory 
and  thus  to  cast  the  problem  in  a more  understandable 
form. 

At  terminals,  as  well,  there  are  different  kinds  of 
"memories,''  ranging  from  pieces  of  paper,  through  the 
terminal  itself,  on  to  computer  memories.  The  general 
goal  is  to  arrange  these  to  complement,  rather  than 
conflict  with,  the  human  memory  of  the  programmer. 

This  general  goal  can  be  broken  down  into  less  general 
areas : 

(1)  For  program  and  system  design,  a useful  style 
is  one  which  helps  a maintenance  programmer 
(a)  to  trace  the  structure  into  which  a modi- 
fication has  to  fit,  and  (b)  to  recognize  the 
functional  blocks  of  which  the  structure  is 
built. 

(2)  The  human  memory  is  volatile  and  fragile,  and 
the  physical  arrangements  at  the  terminal 
should  not  require  the  programmer  to  acquire 
information  from  one  source  and  then  suffer  a 
delay  (plus  possible  distractions)  in  getting 
complementary  information  from  a different 
source . 

(3)  Between  programmer  and  computer,  task  allo- 
cation should  obviously  assign  as  much  "dog 
work"  to  the  computer  as  possible. 

Of  course  people  are  adaptable.  They  work  constantly 
with  arrangements  which  are  not  optimum.  For  example, 
they  take  notes  on  incomplete  displays  of  modules,  or 
they  try  to  remember  things  which,  ideally,  the  computer 
would  be  remembering  for  them.  In  any  case,  they  work 
at  lowered  efficiency.  And  if  the  arrangements  are  too 
discouraging,  programmers  will,  mentally  if  not  physi- 
cally, desert  the  terminal. 

In  summary,  maintenance  programming  poses  problems.  The 
main  guideline  for  terminal  arrangements  should  always 
be  to  try  to  configure  the  problem  in  terms  of  the  dis- 
plays and  memory  assignments  which  are  most  conducive  to 
the  solution  of  the  problem.  The  next  section  will 
present  some  specific  findings  and  recommendations  re- 
sulting from  the  study. 
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4.2  Recommendations  for  Immediate  Implementation 


A major  purpose  of  the  studies  in  terminal  arrange- 
ments was  the  development  of  recommendations  of  value 
to  maintenance  programming.  Several  such  recommenda- 
tions are  made  below. 

Some  of  the  recommendations  could  easily  be  implemented, 
and  others  would  require  additional  research  and/or 
development  work.  Also,  the  evidence  permits  some  to 
be  made  more  firmly  than  others.  The  recommendations 
are  listed  in  the  approximate  decreasing  order  of  ease 
or  immediacy  of  implementation,  and  not  in  order  of 
intrinsic  importance. 

The  section  references  in  the  recommendations  give  the 
locations  of  fuller  discussions  of  the  topics  of 
recommendations . 

(1)  If  a large  program  has  a hierarchical  struc- 
ture, and  if  a maintenance  programmer  is 
allowed  to  familiarize  himself  with  the 
hierarchy  before  doing  detailed  work  at 
different  levels,  he  may  "think  faster"  when 
he  does  begin  work.  (See  Secs.  3. 2. 2.1  and 
3.3.2.)  Except  in  emergencies , such  f amiliar- 
ization  with  the  hierarchy  should  be  recom- 
mended to  the  new  maintenance  programmer. 

(2)  Programmers  should  not  be  required  to  schedule 
terminal  work  for  blocks  of  time  which  seem 
excessively  long.  Although  the  time  a person 
can  work  productively  at  a terminal  is  un- 
questionably a complex  function  of  the  nature 
of  the  program  and  of  other  factors,  there 

is  a limit  on  the  length  of  time  a person  can 
really  concentrate  on  a problem;  inconclusive 
evidence  suggests  that  the  limit  may  sometimes 
be  as  short  as  30  minutes.  In  the  absence 
of  firm  evidence,  self-pacing  of  the  pro- 
grammer's work  is  suggested.  (See  Sec.  3.3.8.) 

(3)  Familiarization  procedures  should  encourage 
new  programmers  not  to  feel  as  if  they  are 

"in  a race  with  the  terminal."  With  the  "race" 
attitude,  a programmer  may  repeatedly  make 
the  same  errors.  (See  Secs.  3.1.4  and  3.3.8.) 
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(4)  When  a new  terminal  system  or  installation 
is  planned,  predictions  should  be  made  re- 
garding the  usage  of  hard  copy  and  other  such 
material  around  the  terminal;  and  the  physical 
facilities  around  the  terminal  should  be 
sufficient  for  this  material.  (See  Secs. 

3.3.6  and  3.3.8.) 

(5)  Program  version  identifiers  should  be  re- 
quired on  each  output  page  (or  terminal 
screen)  to  aid  program  search  operations  by 
the  programmer.  Other  pertinent  input  data 
and  parameters  should  be  readily  available 
on  the  operator's  graphic  screen  or  on  the 
output  page,  to  facilitate  the  maintenance 
process.  (See  Sec.  3.3.5.) 

(6)  People  tend  to  make  mistakes  when  they  "shift 
gears,"  between  different  levels  of  detail, 
when  they  are  working  on  a program.  Both 
tools  and  procedures  should  be  designed  for 
minimizing  unnecessary  shifts  up  and  down 
levels.  (See  Sec.  3.3.2.) 

(6a)  Procedures  partly  depend  on  available 
tools.  But  there  would  be  benefits 
from  simply  giving  the  programmers 
examples  of  shift-related  errors,  and 
encouraging  them  to  schedule  their 
levels  of  work  as  homogeneously  as 
possible. 

(6b)  Split-screen  operations  (allowing 

simultaneous  display  of  two  different 
routines  or  files)  and  note-taking 
routines  (facilitating  temporary  storage 
of  data  needed  later  for  a different 
level  of  analysis)  are  examples  of  use- 
ful tools. 

(7)  Visual  analogs  (defined  in  Sec.  3.3.3)  are 
efficient  tools  for  verifying  the  reasonable- 
ness of  program  functioning,  both  during  de- 
bugging and  after  the  incorporation  of  program 
revision.  Depending  on  the  graphics  terminal 
and  computer  system  being  used,  many  such 
visual  analogs  could  be  developed  at  low 
cost;  they  should  be. 
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(8)  Modularity  should  be  a criterion  for  the 
acceptability  of  large  software  systems. 


(8a) 


For  systems  which  are  large,  but  in 
which  the  per-unit  complexity  is  not 
great,  each  module  should  generally 
be  no  longer  than  40  lines  of  code; 
and  the  module  should  be  developed 
by  only  one  (1)  programmer.  Such  a 
module  can  be  displayed  in  its  en-". 
tirety  on  a screen,  and  it  can  be 
input  and  output  quickly,  and  main- 
tained by  one  person.  (See  Sec.  3.1.2.) 


(8b) 


For  programs  which  are  complex  in 
terms  of  the  implications  of  each 
statement,  a higher  degree  of 
modularity  (i.e.,  smaller  modules  and 
less  dependence  between  modules)  is 
recommended . (See  Sec . 3.2.2.) 


Note:  This  recommendation  also  applies  to 

the  area  of  conceptual  groupings. 


(9) 


Priority  should  be  given  to  the  systematic 
development  of  computer  aided  tools  for 
software  maintenance.  (a)  Those  tools 
which  are  available  tend  to  be  parochial; 
they  should  be  standardized  and  made  more 
transportable  between  computer  systems. 

(b)  Further  tool  development  should  be 
guided  by  the  real  needs  for  the  tools. 
Programmers  may  not  really  know  what  tools 
they  need,  but  they  expressed  a general 
desire  for  a powerful  text  editor  with 
features  of  (i)  insertion,  (ii)  deletion, 

(iii)  substitution,  (iv)  formatting, 

(v)  input,  and  (vi)  paging.  (See  Sec.  3.1.1.) 


(10) 


These  recommendations  are  based  largely  on 
observation  and  experimentation  involving 
the  use  of  FORTRAN;  and,  to  a lesser  extent, 
PL/1.  To  supplement  and  expand  such  recom- 
mendations, there  should  be  additional 
experimentation  and  observations  in  PL/1, 
in  COBOL,  and  in  other  languages. 
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5.  STUDIES  IN  AUTOMATED  CONCEPTUAL  GROUPINGS 


5.1  Introduction  and  Summary 

Often,  to  find  out  how  people  approach  their  work, 
there  is  no  substitute  for  listening  to  them  talk 
about  it.  In  previous  studies,  we  listened  to  pro- 
grammers explaining  their  programs  to  other  pro- 
grammers who  were  going  to  have  to  take  over  mainte- 
nance of  the  programs,  and  to  tape  recordings  of 
programmers  talking  to  themselves  as  they  worked  on 
others'  programs.  The  typical  talk  had  this  "flavor" 
to  it: 

"Now  this  gets  you  into  a big  old  DO-loop,  and 
it  does  so-and-so;  and  along  the  way  you  go  to 
this  other  little  routine  which  stores  the 
results;  and  later  you  go  to  a print  routine. 

II 


From  many  such  spontaneous  words  of  explanation,  it 
is  clear  that  program  statements  are  arranged  into 
groupings;  these  are  the  "natural"  units  of  thought 
for  analyzing  the  program  (at  least  at  the  most  com- 
mon, working  level  of  discourse) . 

The  previous  studies  also  noted  that  these  small, 
elementary  groups  of  program  statements  are  not  the 
ones  the  programmer  typically  chooses  to  describe  in 
formal  documentation.  One  difference  is  in  size:  In 

face-to-face  explanations,  groups  show  a median  size 
of  about  5 lines  or  6 statements  (Overton  et  al., 

1973,  p.  40) , whereas  a median  three  times  as  large 
(17  statements,  to  be  exact)  was  found  in  written 
documentation  (in  an  unpublished  review) . 

It  is  speculated  that  the  origin  of  the  difference  is 
in  the  intent  of  the  programmer:  In  documentation,  he 

may  choose  units  which  minimize  the  work  of  documenta- 
tion; in  face-to-face  explanation,  however,  he  may 
choose  more  basic  and  clearer  explanatory  units. 

If  these  basic  "conceptual  groupings"  could  be  dis- 
played in  some  way,  they  should  (it  was  reasoned) 
help  the  maintenance  programmer  significantly — help 
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him  follow  the  structure  of  the  program  more  easily 
and  rapidly,  and  help  him  identify  the  exact  little 
sections  to  modify. 

The  demonstration  of  the  existence  of  conceptual 
groupings,  and  the  reasoning  about  their  potential 
value,  formed  the  background  to  the  present  Studies 
in  Automated  Conceptual  Groupings. 

In  brief,  pilot  programs  were  developed  to  automate 
display  of  groupings.  PL/1  and  FORTRAN  were  the 
target  languages.  Program  development  was  guided  by 
the  results  of  previous  studies,  supplemented  by 
analysis  of  "marked-up"  listings  (on  which  programmers 
had  scrawled  brackets  around  small  sections  of  state- 
ments as  they  read  and  mentally  grouped  them) . 

Experiments  were  conducted  to  evaluate  the  helpful- 
ness of  such  programs.  (Because  of  scheduling  and 
other  considerations,  the  majority  of  the  experimenta- 
tion happened  to  involve  FORTRAN.)  A principal  find- 
ing was  reported  to  be: 

"Maintenance  programming  efficiency,  at  least 
on  moderately-commented  FORTRAN  programs,  is 
increased  significantly  by  the  use  of  a Con- 
ceptual Groupings  processor." 

In  view  of  the  great  expense  in  maintenance  of  FORTRAN 
programs  (many  of  which  are  not  well  commented) , this 
finding  was  rather  dramatic. 

Experimental  results  with  PL/1  tended  to  be  rather 
anticlimactic.  In  summary,  the  results  with  PL/1 
were  consistently  favorable  to  the  Grouping  Program 
(with  programmers'  expressions  of  opinion  including 
".  . . very,  very  helpful"  and  "Greatl")  but  the  ex- 
perimental data  collected  were  too  small  (in  terms 
of  numbers  of  programmers)  for  the  results  really  to 
be  conclusive. 

In  addition,  there  were  indications  that  the  PL/1 
Grouping  Program  needs  to  be  revised  to  (1)  reflect 
more  adequately  the  habits  that  programmers  bring  to 
PL/1  from  other  languages,  (2)  conform  more  closely 
to  the  structure  and  logic  of  the  language,  and  (3) 
complement  other  tools  for  checking  out  and  maintain- 
ing PL/1  programs. 
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In  spite  of  these  indications,  the  PL/1  Grouping 
Program  seems  capable  of  improving  maintenance  pro- 
grammer productivity  by  ten  or  fifteen  per  cent. 
Hence,  both  it  and  the  FORTRAN  Grouping  Program  merit 
more  development  and  wider  usage. 
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5. 2 Research  Methodology 


The  manner  in  which  a programmer  conceptually  groups 
lines  of  code,  portions  of  files,  etc.,  is  influenced 
by  the  programming  language  in  which  he  is  working. 
Furthermore,  the  features  which  statistically  tend  to 
define  groups,  according  to  the  previous. studies,  vary 
from  language  to  language.  More  precise  definition  of 
these  features,  and  therefore  of  the  advantages  of 
helping  a programmer  recognize  the  groups,  must  be 
done  on  a language-by- language  basis. 

In  consultation  with  ESD  (MCIT) , FORTRAN  and  PL/1  were 
the  target  programming  languages  selected  for  groupings 
analysis.  Attention  was  given  to  FORTRAN  first  in  the 
conceptual  groupings  study.  The  knowledge  and  data 
accumulated  from  the  earlier  RICASM  Studies  were  up- 
dated and  extended  to  select  the  conceptual  groups 
most  likely  to  be  consistent,  easily  identifiable  and 
usable.  Having  made  the  selection,  specifications 
were  established  for  a groupings  programs  using  FORTRAN 
and  PL/1  as  the  target  languages. 

The  first  versions  of  conceptual  groupings  programs 
were  to  be  developed  because  of  the  assumption  that 
such  programs  would  help  a maintenance  programmer 
recognize  useful  groupings,  and  that  this  recognition 
would  facilitate  his  work.  Experimentation  with  the 
first  groupings  programs  would  test  this  assumption, 
and  permit  one  to  say  whether  or  not,  in  actual  practice, 
such  programs  would  be  effective  aids  to  maintenance 
programmers. 

In  general,  an  experimental  conceptual  groupings  pro- 
gram accepts  as  input  a higher-level-language  program 
which  can  be  successfully  compiled.  The  groupings 
program  operates  as  a post-processor;  it  creates  a 
new  listing  which  displays  those  conceptual  groups 
that  the  groupings  program  has  identified  within  the 
source  program. 

For  FORTRAN,  the  experimental  conceptual  groupings 
program  (designated  GP-F)  was  designed  to  accomplish 
the  following  functions:  (1)  identify  groups  by  "like- 

statement  types,"  (2)  print  formats  under  each  refer- 
encing I/O  Statement;  (3)  sort  declaratives  to  begin- 
ning of  the  programs;  (4)  indent  nested  DO  loops; 

(5)  mark  transfer  statements;  and  (6)  mark  I/O  State- 
ments. 
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The  Conceptual  Groupings  Program  for  FORTRAN  was  coded 
in  the  symbol  manipulation  language  SITBOL  (a  version 
of  SNOBOL)  because  of  the  difficulties  in  using  partial 
word  operations  in  FORTRAN  itself.  A complete  program 
description  of  the  Conceptual  Groupings  Program  for 
FORTRAN  (GP-F)  is  found  in  Appendix  B.  The  program 
documentation  includes:  (1)  The  general  system  descrip 

tion;  (2)  Functional  specifications;  (3)  Program  Imple- 
mentation; (4)  Flow  Charts  for  Grouping  Program;  (5) 
Grouping  Program  Listing  (SITBOL) ; (6)  Ungrouped  Source 

FORTRAN  Program  Listing;  and  (7)  Grouped  Source  FORTRAN 
Program  Listing. 

As  part  of  identifying  conceptual  groups  the  groupings 
program  for  PL/1  (GP-P)  was  designed  to  accomplish  the 
following  functions:  (1)  identify  large  conceptual 

groups;  (2)  identify  groups  by  "like- statement  types"; 

(3)  assign  logic  levels;  (4)  repeat  "notes";  (5)  re- 
format declarations;  (6)  indent  nested  control  groups; 
and  (7)  mark  I/O,  Entry,  and  ON-condition  statements. 

The  Conceptual  Groupings  Program  for  PL/1  (GP-P)  was 
coded  in  PL/1  so  that  it  could  later  be  tested  in  an 
operating  environment  with  a manufacturer  supplied 
PL/1  compiler.  A complete  program  description  of  the 
Conceptual  Groupings  Program  for  PL/1  (GP-P)  is  found 
in  Appendix  C.  The  program  documentation  includes: 

(1)  General  System  Description  (GP-P);  (2)  Conceptual 

Groupings  Program  for  PL/1 — Operating  Instructions; 

(3)  Groupings  Program  for  PL/1  System  Block  Diagram; 

(4)  Groupings  Program  for  PL/1  (GP-P)  GP-P  Flow  Charts; 

(5)  Source  PL/1  Program  of  GP-P — Ungrouped;  (6)  Source 
PL/1  Program  of  GP-P — Grouped. 

An  objective  of  the  experimental  design  is  to  get  (1) 
as  free  an  expression  as  possible  of  the  programmers' 
own  observations  and  opinions  of  the  results  of  the 
grouping  processor  (although  these  may  be  biased  by 
adaptation  to  regular  listings,  etc.);  and  (2)  more  ob- 
jective measures  of  performance,  such  as:  success  or 

failure  in  making  a modification  or  finding  an  error; 
rate  of  work;  and  extent  of  use  of  computer  and  other 
resources. 

In  many  quarters,  it  is  an  article  of  faith  that  the 
abilities  of  programmers  differ  tremendously.  [Youngs' 
(1970)  thesis  does  not  fully  support  this  faith.] 
Regardless  of  the  extent  of  differences  between  people, 
the  differences  are  a factor  that  was  considered  in 
deciding  how  to  observe  the  programmers.  This  factor 
was  handled  by  selecting  a homogeneous  group  of  pro- 
grammers at  UCI,  and  by  similar  personnel  selection  at 
the  commercial  facility. 
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For  the  FORTRAN  grouping  experiment,  programmers  were 
students  at  UCI,  all  of  whom  came  to  the  same  class 
with  the  same  background  of  previous  programming 
courses. 

At  the  commercial  facility,  programmers  were  judged 
by  their  supervisors  to  be  of  essentially  equal 
competence . 

The  experimental  design  allowed  the  use  of  objective 
results  for  overall  evaluation  of  the  idea  of  a pro- 
cessor to  introduce  conceptual  groupings  into  a list- 
ing or  other  program  display  medium.  When  the  results 
of  this  study  show  statistically  significant  benefits, 
then  such  benefits  can  be  predicted  with  confidence 
for  a more  efficient  and  more  sophisticated  grouping 
system  in  conjunction  with  its  corresponding  compiler. 

The  subjective  results  were  used  primarily  to  identify 
specific  features  which  did  or  did  not  contribute  to 
the  overall  results.  For  example,  if  everyone  (or 
almost  everyone)  agreed  that  a feature  such  as  showing 
the  nesting  of  DO- loops  was  (or  was  not)  helpful,  then 
one  would  suspect  that  it  did  (or  did  not)  contribute 
positively  to  the  overall  results. 

The  experiments  for  Conceptual  Groupings  in  FORTRAN 
consisted  of  a 3 X 2 analysis  of  variance  type  design. 
The  two  selected  variables  were: 

(1)  Extent  of  post-processor  intervention.  There 

were  three  extents : (l)  No  intervention, 

(2)  use  of  the  half  of  the  grouping  methods 
which  we  consider  "best,"  and  (3)  use  of  all 
grouping  methods. 

(2)  Quality  of  FORTRAN  program  structure  and 
commentary.  There  were  two  quality  levels : 

(1)  "Good,"  in  the  sense  of  being  clearly 
better  than  normal  practice,  but  not  con- 
spicuously outstanding;  (2)  "Fair,"  but  not 
atrocious. 

The  resulting  six  data  cells  then  appear  as  illustrated 
in  Figure  6. 
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Figure  6 

Experimental  Design  for  Groupings 
Experiments  in  FORTRAN 

5.3  Execution  of  Method 

In  all,  64  programmers  were  utilized  in  the  FORTRAN 
grouping  experiment  among  the  student  population  at 
the  University  of  California,  Irvine.  The  programmers 
were  to  make  specific  enhancements  to  a selected 
FORTRAN  program.  The  experimental  design  required  at 
least  ten  programmers  to  incorporate  the  program 
enhancements  under  the  correlations  of  each  cell.  The 
independent  variables  to  be  measured  were:  (1)  time 

taken  to  complete  the  task;  and  (2)  degree  of  success. 

The  experimental  design  suggested  that  if  statistical 
significance  can  be  achieved,  the  data  will  obviously 
contribute  to  answers  to  a number  of  questions,  in- 
cluding the  following: 

1.  Does  the  groupings  processor  help  maintenance 
of  FORTRAN  programs? 

2.  Do  the  groupings  help  less  (or  more)  on  "good" 
programs? 

3.  How  good  is  our  judgment  of  which  groupings 
methods  in  FORTRAN  are  most  helpful? 

The  experimentation  involving  PL/1  was  conducted  at  a 
local  industrial  plant.  (It  was  selected  because  PL/1 
was  being  used  there,  and  because  the  management  agreed 
to  let  AMS  conduct  experimentation  at  the  plant. ) How- 
ever, because  of  the  small  number  of  programmers  the 
plant  could  make  available  to  us,  the  experimental  design 
was  compressed  from  six  cells  (as  shown  in  Fig.  6)  to  two 
rationale:  Use,  or  non-use,  of  the  PL/1  groupings  program. 
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6. 


EFFECTS  ON  MAINTAINABILITY 


RESULTS 7 


6.1  Introductory  Findings 


6.1.1  Previous  Data 

Although  the  data  obtained  on  conceptual  groupings  was 
by  interview  and  manual  experimentation  on  the  previous 
CASMS  and  RICASMS  efforts  (Overton  et  al. , 1971,  1973) 
two  major  facts  emerged  about  conceptual  groupings  and 
their  usage: 

First,  the  groups  that  maintainers  use  are  small  in 
terms  of  the  number  of  lines  of  code  involved. 

Second,  a very  small  number  of  group  types  include  a 
very  high  fraction  of  all  observed  groupings.  These 
group  types  are  for  the  most  part  simply  defined;  they 
should  lend  themselves  easily  to  automated  maintenance 
aids  for  clarifying  programs  to  be  maintained. 

In  terms  of  the  sizes  of  explicit  groupings,  the  find- 
ings were:  The  groupings  were  (1)  Small,  but  (2)  Skewed 

in  distribution  toward  the  larger  sizes. 

Furthermore  the  experimentation  showed  that  the  seven 
most  frequently  specified  groups  were: 

(1)  I/O:  This  group  consists  of  input/output  and 

closely  related  statements. 

(2)  DO:  A group  starting  with  a DO  statement 

and  ending  with  the  last  executable  statement 
within  the  range  of  the  loop. 

(3)  IF:  A conditional  statement  primarily  in- 

volved in  an  if  statement. 

(4)  GO  TO:  Ending  with  an  unconditional  transfer. 

(5)  ASSIGN:  A group  of  statements,  mostly  FORTRAN 

assignment  statements. 

(6)  DEC:  Consists  of  FORTRAN  declaration  statements. 

(7)  DESCRIP:  Consists  of  COBOL  description  state- 

ments (data  or  file) . 
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The  clear  implication  of  these  two  results  is  that  the 
known  characteristics  of  conceptual  groupings  should  be 
incorporated  in  actual  maintenance  aids.  These  findings 
were  taken  into  consideration  in  the  design  of  the 
Conceptual  Grouping  experimentation  using  PL/1  and 
FORTRAN  under  the  current  effort. 


6.1.2  Confirmatory  Observations 

While  this  was  the  first  time  that  pilot  programs  had 
been  developed  to  attempt  to  display  Conceptual  Group- 
ings, they  had  been  manually  studied  previously.  Those 
studies  produced  specifications  as  to  the  kinds  of 
statements  which  typically  marked  the  beginnings  and 
ends  of  groupings,  and  the  kinds  of  statements  they 
typically  contained. 

These  findings — statistical  markers  in  a sense — were  the 
guides  for  the  pilot  programs  developed  here. 

They  were  supplemented — in  PL/1  particularly — by  obser- 
vations of  what  were  called  "marked-up"  program  listings. 
This  phrase  refers  to  a technique  Which  was  developed 
previously:  Rather  than  having  every  programmer  talk 

out  loud,  some  were  told  to  simply  draw  rough  cups  or 
brackets  around  groups  of  statements  as  they  read  and 
studied  them.  It  was  found  that  if  the  programmers  did 
not  have  to  write  down  any  words — just  mark  lines — their 
markings  roughly  corresponded  to  their  orally-expressed 
conceptual  groupings. 

The  marked-up  FORTRAN  sheets  collected  here  tended  to 
confirm  previous  findings  regarding  the  characteristics 
of  conceptual  groupings  in  FORTRAN. 

Those  in  PL/1  led*  to  the  conclusion  that  programmers 
tend  to  treat  PL/1  like  the  older  languages,  which  they 
learned  first,  which  they  happen  to  be  most  familiar 
with.  Therefore  other  languages,  in  addition  to  the 
marked-up  listings,  were  used  as  guides  to  the  develop- 
ment of  the  grouping  program  for  PL/1.  Included  in  the 
other  languages  was  COBOL,  of  which  a pilot  study  had 
been  made. 

After  the  programs  had  been  developed,  the  primary  use 
of  them  was,  of  course,  in  experimentation.  However,  to 
confirm  the  results  of  the  experimentation,  some  pro- 
grammer opinions  were  solicited. 

The  salient  finding  was  that  no  one  objected  to  the 
groupings  display;  and  most  felt  that  the  grouping  con- 
cept was  helpful. 
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Suggestions  included: 


(1)  The  more  frequently  control  is  transferred 
to  a given  point  in  a program,  the  more 
emphasis  should  be  placed  on  that  point. 

(2)  Some  information  available  in  conventional 
documentation  should  be  incorporated  into 
the  displays  of  groupings.  For  example, 
system  subroutines  (as  distinguished  from 
subroutines  in  the  application  program) 
should  be  identified. 

(3)  If  the  original  programmer  specifies  the 
range  of  statements  to  which  a comment 
applies,  this  information  should  be  used 

to  specify  a grouping.  This  could  be  broken 
into  subgroupings  if  necessary. 

Because  these  suggestions  arose  late  in  the  course  of 
this  project,  it  was  not  possible  to  implement  them 
in  the  present  pilot  programs.  If  they  were  imple- 
mented as  appropriate  in  the  programs,  and  if  further 
data  on  PL/1  groupings  were  obtained,  such  groupings 
processors  should  offer  even  more  practical  help  to 
maintenance  programmers. 


6. 2 Grouping  Studies  Using  FORTRAN 


This  was  the  most  extensive  experiment  carried  out  and 
involved  64  student  programmers  at  the  University  of 
California  at  Irvine.  Most  were  going  to  school  part- 
time  and  were  employed  full-time  in  industry.  Experi- 
mentation was  incorporated  into  normal  classroom  activi- 
ties by  the  professor.  Dr.  Peter  Freeman.  The  assign- 
ment was  to  incorporate  selected  changes  in  a FORTRAN 
Program  (see  Appendix  B)  which  had  been  grouped  accord- 
ing to  the  experimental  conditions  outlined  in  paragraph 
5.2  above.  The  time  spent  to  incorporate  the  change 
was  recorded.  Then  the  professor  reviewed  the  pro- 
grammers' listings  and  program  execution  data  and  assigned 
an  adequacy  score.  The  "raw  data"  from  the  experimenta- 
tion are  presented  in  Table  1. 


TABLE  1 

RAW  DATA  CONCEPTUAL  GROUPINGS  STUDY 
FOR  FORTRAN 


Experimental  Programmer  Adequacy  Time  of 

Condition*  Score  Effort  (min) 


1 

3 

70 

20 

1 

16 

65 

45 

1 

33 

55 

40 

1 

36 

30 

55 

1 

38 

35 

58 

1 

43 

40 

50 

1 

44 

30 

45 

1 

57 

65 

45 

1 

63 

40 

45 

1 

64 

45 

55 

2 

4 

65 

59 

2 

12 

65 

41 

2 

21 

70 

60 

2 

22 

30 

52 

2 

25 

75 

20 

2 

29 

75 

49 

2 

47 

30 

40 

2 

50 

50 

50 

2 

52 

75 

34 

2 

59 

65 

40 

2 

61 

65 

58 

3 

1 

75 

30 

3 

7 

75 

35 

3 

14 

30 

51 

3 

26 

65 

48 

3 

39 

75 

50 

3 

40 

40 

48 

69 


TABLE  1 (continued) 


Experimental 

Condition* 

Programmer  Adequacy  Time  of 

Score  Effort  (min) 

3 

41 

75 

42 

3 

42 

70 

39 

3 

53 

70 

28 

3 

56 

40 

55 

3 

58 

75 

45 

3 

60 

75 

60 

4 

6 

75 

60 

4 

9 

65 

50 

4 

10 

70 

59 

4 

11 

65 

40 

4 

23 

75 

45 

4 

28 

75 

31 

4 

35 

75 

35 

4 

49 

35 

50 

4 

51 

40 

15 

4 

55 

75 

26 

5 

8 

70 

32 

5 

15 

75 

58 

5 

20 

75 

30 

5 

31 

75 

46 

5 

34 

50 

35 

5 

37 

70 

55 

5 

45 

30 

49 

5 

46 

75 

19 

5 

48 

75 

59 

5 

54 

65 

59 

5 

62 

30 

55 

6 

2 

75 

43 

6 

5 

40 

52 

6 

13 

55 

33 

6 

17 

70 

17 

6 

18 

75 

55 

6 

19 

75 

43 

6 

24 

55 

65 

6 

27 

50 

60 

6 

30 

75 

40 

6 

32 

40 

40 

♦Condition 

Is 

Minimal 

commenting. 

no  grouping 

2: 

Minimal 

commenting , 

"best-half" 

grouping 

3: 

Minimal 

commenting, 

full  grouping 

4: 

Full  commenting,  no 

grouping 

Full  commenting,  "oest-nair"  gi 
Full  commenting,  full  grouping 
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The  data  are  summarized  in  Table  2.  The  basic  compari- 
sons of  interest  are  those  among  the  six  experimental 
conditions.  (The  statistically  "combined  conditions" 
are  shown  in  the  bottom  row  and  right  column  of  the 
table.)  The  meaningful  comparisons  are  between  the 
mean  adequacy  scores  under  different  conditions.  It 
is  immediately  seen  that  the  worst  (or  lowest)  mean  is 
a product  of  minimal  commenting  and  no  help  from  the 
grouping  program. 

Significant  improvement  appears  under  two  conditions: 

(1)  when  the  "Best  Half"  grouping  algorithms  are  ap- 
plied to  minimally-commented  code/  and  (2)  when  the 
full  set  of  procedures  is  applied  to  the  same  code. 

(The  word  "significant"  is  used  in  its  statistical 
sense  as  well  as  in  its  ordinary  connotation.  When 
minimal  commenting  is  used,  both  the  "Best  Half"  and 
the  full  grouping  procedures  give  results  which, 
according  to  the  "t"  test  for  the  difference  between 
means,  differ  signTf icantly  from  the  results  with  no 
grouping  procedures.  The  t values  are  1.867  for  the 
"Best  Half"  and  2.401  for  the  full  procedures;  the 
"degrees  of  freedom"  necessary  to  interpret  these  t's 
in  standard  statistical  tables  are,  respectively,  19 
and  20.  According  to  the  statistical  tables,  the 
probability  of  the  results  arising  by  chance  is  less 
than  .05.) 

Thus,  in  the  realistic  condition  of  poorly-commented 
FORTRAN,  this  prototype  grouping  program  is  shown  to 
be  an  effective  aid  to  the  maintenance  programmer. 


t 
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TABLE  2 


SUMMARY  DATA 

CONCEPTUAL  GROUPINGS  STUDY  FOR  FORTRAN 


No  Grouping 

"Best-Half" 

Full 

Grouping 

Combined 

Procedures 

Grouping 

Procedures 

Conditions 

Minimal 

M* 

— 

47.5 

M 

= 

60.4 

M 

= 

63.8 

M 

= 

57.7 

Commenting 

N* 

= 

10. 

N 

= 

11. 

N 

= 

12. 

N 

= 

33. 

S* 

= 

15.1 

S 

= 

16.6 

S 

= 

16.8 

S 

= 

17.2 

"Full" 

M 

_ 

65.0 

M 

= 

62.7 

M 

— 

61.0 

M 

SS 

63.9 

Commenting 

N 

= 

10. 

N 

= 

11. 

N 

= 

10. 

N 

= 

31. 

S 

15.1 

S 

“ 

17.8 

S 

“ 

14.7 

S 

15.5 

Combined 

M 

_ 

56.2 

M 

= 

61.6 

M 

= 

62.5 

M 

= 

60.2 

Conditions 

N 

= 

20. 

N 

= 

22. 

N 

= 

22. 

N 

= 

64. 

S 

17.2 

S 

= 

16.8 

S 

= 

15.6 

S 

= 

16.5 

Notes:  *M  = Mean  score  of  adequacy  of  maintenance  effort. 

N = Number  of  programmers. 

S = Standard  deviation  of  scores. 


6.3  Grouping  Studies  Using  PL/1 

In  brief,  PL/1  results  were  not  comparable  to  those  with 
FORTRAN.  They  were  encouraging,  but  further  develop- 
ment of  the  PL/1  grouping  concept,  in  relationship  to 
other  maintenance  tools,  is  needed. 

Experimentation  with  FORTRAN  provided  dramatic  evidence 
that  the  Grouping  Program  significantly  facilitated 
maintenance.  Experimentation  with  PL/1  turned  out  to 
be  anticlimactic.  The  PL/1  Grouping  Program  did  not 
fail  to  be  helpful,  but  the  results  were  obscured  by 
several  factors:  Intrinsic  differences  between  PL/1 

and  FORTRAN  and  effects  of  these  differences  on  program- 
mers, different  availability  of  compiler  features,  and 
the  less  thorough  development  of  the  PL/1  Grouping 
Program. 

PL/1  study  procedures  and  results  are  described  and 
discussed  below. 


6.3.1  Procedures 

There  were  about  2,100  statements  in  the  PL/1  applica- 
tion program  which  was  used  to  test  the  PL/1  Grouping 
Program.  The  application  program  was  essentially  a 
large  report  writer  capable  of  presenting  a large  variety 
of  labor  cost  data  and  otfher  financial  data  in  various 
formats.  It  was  the  subject  of  considerable  maintenance 
work  at  the  installation  using  it,  which  was  the  computer 
service  department  of  the  electronics  and  related 
divisions  of  a large,  diversified  corporation. 

Enhancements  and  other  modifications  were  actually  being 
made  in  the  applications  program  by  department  program- 
mers who  were  not* among  the  original  developers  of  the 
program.  Two  sets  of  enhancements  were  used  in  the 
studies  reported  here.  (Time  did  not  permit  more  ex- 
tensive experimentation.)  As  a result  of  this  working 
situation,  the  studies  were  cast  in  a real-life  environ- 
ment and  not  in  an  artificially  contrived  situation. 

The  two  sets  of  enhancements  were  made  by  two  different 
two-man  teams  of  maintenance  programmers:  a senior  and 

a junior  programmer  formed  each  team.  Their  supervisors 
gave  them  the  assignments  and  mentioned,  without  elabora- 
tion, that  they  would  use  a new  kind  of  program  listing 
in  their  work. 
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Unlike  the  FORTRAN  procedure,  comparable  programmers 
were  not  given  the  same  assignment  with  a different 
listing.  Instead,  the  supervisors  made  the  assignments 
with  a view  of  past  work  which  they  thought  was  equiva- 
lent in  difficulty,  and  with  which  they  could  compare 
the  results  with  the  listings  from  the  PL/1  Grouping 
Program.  The  basic  data,  then,  were  simply  the  per- 
centages of  the  man-hours  needed  to  do  the  present 
assignments  in  comparison  with  past  assignments  (to  the 
same  people)  which  were  thought  to  be  equivalent. 

It  should  be  emphasized  that  these  percentages  were  esti- 
mated, not  by  A.M.S.  personnel  and  not  by  the  working 
programmers  themselves,  but  by  the  programmers'  super- 
visors on  the  basis  of  time  cards  and  other  records  and 
questioning  of  the  programmers.  The  making  of  the  esti- 
mates by  the  supervisors  may  have  introduced  a slight 
bias  in  favor  of  the  normal  procedures  of  the  supervisors' 
department  and  against  the  experimental  listing.  Of 
course  the  extent  of  this  bias,  if  any,  is  not  known. 

In  contrast  to  the  quantitative  estimates  sought  from 
the  supervisors,  qualitative  reactions  were  solicited 
from  the  programmers.  The  reactions  were  requested 
directly  by  A.M.S.  personnel,  and  not  by  the  programmers' 
supervisors. 

In  summary,  these  procedures  were  planned  to  produce  two 
quantitative  estimates  and  two  sets  of  qualitative 
opinions. 


6.3.2  Results 

One  assignment  was  estimated  as  a four  man-day  job  on 
the  basis  of  a presumably  equivalent  past  assignment 
using  ordinary  listings.  Using  the  experimental  listing 
produced  by  the  PL/1  Grouping  Program,  the  assignment 
was  completed  in  about  ten  per  cent  less  time  than  this , 
that  is,  in  a little  over  3-1/2  man-days. 

The  second  assignment  was  estimated,  by  the  same  procedure, 
as  a nine  man-day  job.  It  was  completed  in  a little  over 
7-1/2  man-days,  for  a fifteen  per  cent  saving  in  time 
which  might  be  attributed  to  the  Grouping  Program. 

Great  consistency  was  found  among  the  subjective  opinions 
of  the  four  programmers.  (There  was  no  difference  of 
opinion  between  the  junior  and  the  senior  programmers.) 

Two,  who  had  been  using  conventional  listings,  described 
the  grouped  output  as  "Great! " and  "very,  very  helpful." 
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The  reaction  of  the  other  two  was  more  complicated.  They 
had  been  using  a "Checkout  Compiler"  as  an  option  with 
IBM's  "TSO"  or  Time-Sharing  Option"  with  the  department's 
IBM  system.  They  tended  to  equate  the  Grouping  Program 
with  the  Checkout  Compiler#  which  was  described  as  being 
"invaluable. " 

In  their  opinion,  the  Grouping  Program  treated  commentary 
better  than  did  the  Checkout  Compiler.  But  they  criticized 
the  Grouping  Program  for  relying  too  much  on  GO  TO's  as 
signals  of  conceptual  groups. 

In  summary,  the  results  were  consistently  favorable  but 
they  were  based  on  insufficient  experimentation  to  be 
statistically  significant  and  they  may  have  been  confounded 
by  the  effects  of  other  tools  to  which  two  of  the  pro- 
grammers were  accustomed. 


6.3.3  Discussion 

Some  minor  observations  indicated  that  the  present  version 
of  the  PL/1  Grouping  Program  should  conform  more  closely 
to  the  characteristics  of  the  PL/1  language.  For  example 
one  programmer  observed  that  the  FORTRAN  version  helped 
show  up  a "trick"  whereby  a limitation  of  FORTRAN  in  the 
treatment  of  negative  limits  and  subscripts  could  be 
avoided;  he  said  that  since  PL/1  does  not  have  this  limi- 
tation, the  trick  would  not  be  necessary  and  therefore 
would  not  have  to  be  pointed  out. 

More  basically,  the  reported  over-reliance  on  GO  TO's  may 
indicate  the  program  does  not  yet  conform  as  well  as  it 
should  to  the  greater  degree  of  block  structure  in  PL/1 
as  opposed  to  FORTRAN. 

It  was  also  a general  opinion  that  programmers  tend  to  use 
sub-sets  of  PL/1  which  are  comparable  to  whatever  older 
language  they  happened  to  be  using  before  they  started  on 
PL/1.  Perhaps,  in  retrospect,  more  work  should  have  been 
done  on  older  languages  before  beginning  PL/1. 

Finally,  future,  practical  versions  of  the  PL/1  Grouping 
Program  should  be  coordinated  with  other  tools  such  as 
the  Checkout  Compiler,  to  complement  as  much  as  possible 
the  features  of  the  other  tools. 


* •' 
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7.  IMPLICATIONS  AND  RECOMMENDATIONS 


7.1  Developing  Automated  Guidelines 

The  methodology  has  now  been  evolved  for  defining , and 
validating  through  experimentation,  computer  software 
which  will  be  of  value  in  aiding  the  software  mainte- 
nance process  ("Guidelines"),  and  in  measuring  the 
degree  of  maintainability  ("Metrics")  of  software  under 
development.  The  Conceptual  Grouping  Guideline  for 
FORTRAN  and  for  PL/1  can  be  specified  as  a guideline 
for  future  AFSC  software  development.  The  prototype 
computer  programs  outlined  in  Appendices  B and  C can 
be  converted  into  operational  routines.  (These  could 
be  incorporated  as  post-processors  to  their  respective 
compilers,  or  they  could  be  developed  as  modules  of  a 
computer-aided  software  metrics  system.)  Measures  of 
conceptual  grouping  conformance  can  easily  be  speci- 
fied which  will  evaluate  software  under  development 
and  give  indications  of  the  places  where  improvement 
could  be  made. 

The  Conceptual  Groupings  guideline  has  been  virtually 
defined  for  FORTRAN,  and  most  of  the  development  for 
PL/1  is  complete.  The  methodology  should  next  be 
applied  to  the  other  major  programming  language  in  the 
AFSC  inventory,  COBOL. 

The  methodology  developed  is  applicable  to  developing 
other  maintainability  guidelines  and  their  correspond- 
ing metrics.  A careful  review  should  be  conducted  of 
the  software  maintainability  guidelines  that  have  been 
evolved  to  aid  in  solving  the  fundamental  factors  which 
inhibit  a programmer  from  maintaining  computer  programs 
he  did  not  develop.  Selection  should  be  made  of  these 
guidelines  from  ESD  TR  72-121  (Overton  et  al.,  1971) 
and  ESD  TR  73-125  (Overton  et  al.,  1973)  which  have 
high  potential  for  both  enhancing  software  maintenance 
and  for  effective  quantization.  Of  immediate  attention 
are  the  DISTANCE  guidelines  and  the  NOTE  guidelines. 
Objective  measures  need  to  be  developed  for  each 
selected  guideline.  Then  experiments  would  be  designed 
to  objectively  evaluate  the  measures,  experiments  which 
are  economic,  and  for  which  sufficient  programmer  popu- 
lations can  be  selected  to  establish  reasonable  statisti- 
cal significance  to  the  results.  In  this  manner  a set  of 
automated  guidelines  can  be  developed  to  both  assist  in 
and  evaluate  software  maintainability  performance. 
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7 . 2 Developing  A Computer  Aided  Software 
Maintenance  Metrics  System 

It  appears  feasible  to  begin  the  synthesis  of  the 
research  and  development  efforts  conducted  in  a Study  of 
Fundamental  Factors  Underlying  Software  Maintenance 
Problems  (ESD  TR-72-121) , and  Research  Toward  Ways  of 
Improving  Software  Maintenance  (ESD  TR- 73-125)  and  this 
effort  in  Development  of  Computer  Aided  Software  Mainte- 
nance into  a Computer  Aided  Software  Maintenance  Metrics 
System. 

The  envisioned  graphics  system  would  encompass  both 
computer  assisted  techniques  of  software  maintenance 
evaluation  while  new  systems  are  under  development  and 
of  program  analysis,  change  determination,  and  error 
discovery,  for  systems  undergoing  test  and  change. 

The  approach  taken  would  be  to  develop  a conceptual 
structure  of  the  overall  interactive  graphics  system, 
implementing  selected  maintainability  guidelines  in  the 
form  of  metrics  sub-program  modules  as  their  definition 
and  quantization  are  established  and  verified.  The 
graphics  system  as  developed  should  be  compatible  with 
more  than  one  potential  user  system  of  interest,  and 
provide  for  handling  FORTRAN,  PL/1  and  COBOL  programming 
languages . 

The  design  of  the  executive  and  control  structure  of  the 
Metrics  System  should  use  a top-down  structure.  The 
design  should  begin  with  a global  system  flow  chart  and 
description,  followed  by  detailed  system  decision  de- 
scriptions for  all  the  system  functions. 

Although  it  is  called  a "program"  to  emphasize  its 
automatic  nature,  the  contemplated  Metrics  Program  is 
actually  a system  of  programs.  A possible,  simplified, 
top-level  flow  chart  of  the  overall  system  is  shown  in 
Figure  7 . The  major  factor  behind  the  proposal  of  this 
particular  kind  of  configuration  is  that  it  permits 
flexibility  in  the  detailed  design  of  the  component 
Metrics  Sub-programs.  In  addition  to  executive  and 
control,  other  functions  are  combining  the  results  of 
the  Metrics  Sub-programs,  and  input-output  functions. 

The  Combining  Module  is  important.  Initially  some  simple 
scheme  should  be  selected  for  calculating  a weighted 
average  (of  the  ratings  of  other  sub-program  main- 
tainability) from  the  different  ratings  of  the  Metrics 
programs.  At  some  future  time,  however,  it  would  be 
desirable  to  develop  an  "intelligent"  Combining  function 
which  would  include  the  use  of  people's  judgments  (of 
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program  maintainability)  as  a criterion  against  which 
to  optimize  the  weighting  factors.  In  other  words,  it 
might  be  well  to  assume  that  people  are  still  better 
than  computers  at  deciding  how  hard  it  is  to  change 
programs,  and  have  the  computer  system  conform  itself 
to  the  human  standards. 

By  maintaining  a top-down  structure  to  the  metrics 
executive  system,  and  a modularized  approach  to  the 
metrics  sub-programs,  a highly  effective  graphics 
system  could  be  evolved  over  time.  The  system  could  be 
revised  and  improved  to  better  assist  the  maintenance 
programmer  as  more  techniques  are  identified  and 
quantized. 
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DEVELOPMENT  OF  COMPUTER  SOFTWARE  METRICS  SYSTEM 


Figure  7..  Proposed  Top-level  Flow  Chart  of  Metrics  System 


7.3  Recommendations  for  Immediate  Implementation 


The  principal  purpose  of  the  studies  in  conceptual 
groupings  was  the  evaluation  of  such  groupings  as  aids 
to  maintenance;  i.e.,  do  they  help  the  maintenance  pro- 
grammer, and  can  they  be  automatically  displayed  for 
his  assistance?  The  answer,  disregarding  the  qualifica- 
tions and  cautions  that  one  would  expect  from  a pre- 
liminary development  project,  was  yes. 

Accordingly,  the  basic  recommendation  is  (to  quote 
from  an  abstract  of  the  study) : "Pilot  programs  were 

developed.  . . . Such  programs  merit  wider  usage. " 

The  "merit"  is  economic.  Beginning  with  an  estimate 
of  U.S.  annual  software  cost  of  $10  billion  (Boehm  1973), 
and  (1)  assuming  that  U.S.A.F.  costs  are  10%  of  that 
total;  (2)  50%  of  the  U.S.A.F.  cost  is  applicable  to 
software  maintenance;  (3)  the  groupings  concept  applies 
to  only  20%  of  the  software  documentation;  and  (4)  a 
minimum  of  10%  efficiency  improvement  is  experienced; 
then,  the  total  savings  to  the  Air  Force  would  exceed 
$10  million  per  year! 

To  be  most  profitable,  the  future  work  should  be 
coordinated  with  available  compiler  tools  (as  discussed 
in  Sec.  3.1.1).  New  groupings  programs  should  also 
include  the  new  features  described  in  Sec.  6.1.2. 

In  addition  to  the  continued  development  which  the 
above  basic  recommendation  implies,  some  recommendations 
can  be  made  which  can  be  implemented  in  short  order,  or 
by  administrative  fiat.  These  are  listed  below. 

The  listings  include  the  sections  of  this  report  which 
present  the  backgrounds  of  the  recommendations.  Some 
references  are  also  made  to  a following  section  (8.1, 
Alternative  Perspectives  of  a Program)  which  overlaps 
both  the  graphic  terminal  arrangements  and  automated 
groupings  studies. 

(1)  Conventional  documentation  of  a program  would 
probably  be  improved  if  programmers  were  re- 
quired to  use  smaller  documentation  units. 

Such  requirements  or  encouragements,  by  ad- 
ministrative directive,  are  recommended. 

(la)  "Smaller"  means,  for  most  programs,  and 
in  rough,  order-of -magnitude  terms,  that 
the  average  documentation  unit  should 
include  closer  to  six  than  to  sixty 
statements.  (See  Sec.  5.1.) 
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(lb)  For  programs  of  high  intrinsic  complex- 
ity (which  scientific  programs  may  be, 
in  contrast  to  simple  bookkeeping  pro- 
grams) , the  value  of  smaller  functional 
units  is  even  greater.  (See  Sec.  3.2.3.) 

(2)  Programmers  should  be  encouraged  to  work  in 
terms  of  small  computational  routines  for 
performing  one  and  only  one  transformation  on 
one  variable  or  subvariable  (as  contrasted 
with  routines,  which  may  be  more  efficient  in 
computer  usage,  which  utilize  a statement  to 
affect  more  than  one  variable) . (See 

Sec.  8. 1.4. 2.) 

(3)  In  software  systems  having  a definite  hierarchy, 
higher-level  groups  should  involve  only  higher- 
level  variables.  (For  example,  total  trans- 
portation cost  is  a higher-level  variable  than 
either  loading  costs  or  trucking  costs;  and 
total  cost  is  a higher-level  variable  than 
total  transportation  cost.)  (See  Sec.  8. 1.4. 2.) 
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8.  FUTURE  RESEARCH  RECOMMENDATIONS 


8.1  Alternative  Perspectives  of  a Program 

Useful  research  is  sometimes  inspired  by  a new  view  of 
an  old  problem.  This  section  puts  forth  the  radical 
view  that  all  programming  is  simulation,  and  that  the 
problems  of  maintenance  programming  relate  to  the  in- 
adequacies of  some  simulations. 

8.1.1  Programming  as  Simulation 

A novel  view  of  computer  programs  has  been  offered  by 
Licklider  (1973,  p.  199): 

"Instead  of  thinking  of  a computer  program  as  a 
procedure  for  solving  a problem,  we  can  think  of 
it  as  a description  of  a process — as  a descrip- 
tion of  how  some  system  works.  The  system  may  be 
simple  or  complex,  actual  or  merely  imagined.  In 
a computer  program,  one  can  describe  it  precisely 
and  definitely.  Then,  when,  the  program  is  fed 
into  a computer  and  the  'start'  button  is  pushed, 
the  description  turns  into  a working  model  or 
simulation. " 

From  this  point  of  view,  then,  an  inventory  control 
program  merely  describes  the  work  which  a human  clerk 
would  do  if  he  were  fast  enough;  and  routines  for 
computer-aided  design  try  to  simulate  human 
mathematician-helpers  (again,  at  high  speed). 

In  short,  Licklider  is  saying  that  all  programs  are 
simulations.  The  present  authors  add  two  thoughts: 

(1)  that  the  programmer's  view  of  perspective  of  a 
program  is  also  a simulation,  and  (2)  that  maintenance 
includes  an  attempt  to  bring  the  two  kinds  of  simula- 
tions into  some  kind  of  congruence. 

8. 1.1.1  An  Alternate  Abstract 

To  illustrate  the  fact  that  different  things  can  be 
seen  in  the  same  lines,  the  authors  present  an  alter- 
nate abstract  which  was  originally  written  only  for 
diversion: 

"There  were  studies,  notes  and  measures  to  find 
what  helped  and  hindered  people  who  modified  com- 
puter programs.  Environments  were  batch  and 
time-share,  using  PL/1  and  FORTRAN. 
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People  at  time-sharing  consoles  were  handicapped 
by  scattered  sources  of  the  data  that  they  needed; 
the  summed  effect  of  small  distractions  was  a 
surprising  loss  of  time. 

In  batch,  help  was  drawn  from  'groupings'  corre- 
lating lines  and  'concepts. ' Pilot  programs  were 
developed  to  automate  display  of  'groupings'; 
such  programs  merit  wider  usage." 

This  alternate  abstract  contains  a rhythm,  and  people 
tend  to  notice  it.  But  a text  processing  software 
system  (which  could  accept  the  alternate  abstract  as 
input)  could  not  "notice"  the  rhythm.  Figuratively 
speaking,  the  computer  lives  in  a world  in  which 
rhythm  does  not  exist. 

Computers  respond  to  other  things.  For  example,  com- 
pilers like  to  count  parentheses  and  report  errors  if 
open-  and  close-parentheses  do  not  match. 

These  "things,"  such  as  the  presence  or  absence  of 
rhythm,  or  the  matching  or  non-matching  of  parentheses, 
may  loosely  be  called  variables,  attributes,  or 
dimensions.  Returning  to  the  idea  of  simulations,  any 
simulation  may  be  described  in  terms  of  the  dimensions 
along  which  it  calculates.  And,  as  will  be  discussed 
below,  people  and  programs  tend  to  work  within  the 
frameworks  of  different  sets  of  dimensions. 


8. 1.1. 2 Presence  and  Absence  Effects 

Once  there  was  a payroll  program  which  incorporated  a 
defense  against  at  least  one  form  of  sophisticated 
deceit  by  employees.  The  time  cards,  which  the  em- 
ployee filled  out  and  signed,  were  machine-readable, 
and  they  included  a group  of  holes  which  told  each 
employee's  hourly  rate  of  pay.  The  rate  codes  could 
easily  be  read  by  a person,  too,  if  he  knew  the  common, 
standard  card  format.  So  a sophisticated  employee 
could  have  "doctored"  his  card  to  give  himself  a rate 
* of  pay  of,  say  $99.99  per  hour.  (Also,  he  would  be 
the  only  person  to  see  his  paychecks.) 

As  a defense  against  this  possibility,  the  developers 
of  the  payroll  program  created  a test  for  paycheck 
amounts  If  the  amount  was  more  than  what  seemed,  to 
the  systems  analysts  at  the  time,  to  be  a reasonable 
maximum,  the  program  refused  to  write  the  check. 

Six  years  passed.  There  was  personnel  turnover  in  the 
business  programming  department.  Then,  when  the  company 
started  laying  off  some  professional  employees,  a "bug" 
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appeared  in  the  payroll  program.  It  refused  to  write 
some  of  the  employees'  final  paychecks.  (Thus,  inci- 
dentally, adding  insult  to  injury  on  their  lay-offs.) 

After  spending  a significant  amount  of  frantic  people- 
time, plus  spending  some  computer  time,  and  suffering 
considerable  embarrassment,  the  programming  department 
tracked  down  the  "bug."  It  was,  of  course,  the  old  test 
for  deceit  in  time  cards  . . . still  working  exactly  the 
way  the  program  said  it  should. 

The  program's  problem  was  that  (1)  it  took  no  account 
of — or  failed  to  simulate — the  effects  of  six  years  of 
inflation;  and  (2)  it  failed  to  simulate  a world  in 
which  lay-offs  took  place — especially  to  well-paid 
people  who  might  have  accumulated  up  to  four  weeks' 
vacation  time,  to  be  added  to  their  final  paycheck.  In 
this  new,  real  world,  the  "reasonable"  maximum  of  six 
years  ago  was  no  longer  reasonable. 

Conversely,  to  understand  the  apparent  "bug,"  the  current 
maintenance  programmers  had  to  mentally  "simulate"  a 
world  in  which  employees  might  fraudulently  alter  their 
time  cards. 

In  general,  a maintenance  programmer  will  be  baffled  by 
the  workings  of  a system  which  simulates  the  presence  of 
a dimension  of  which  the  programmer  does  not  happen  to 
think.  Until  he  does  think  of  it,  he  will  be  bewildered 
— like  a creature  of  the  mythical  Flatland  trying  to 
imagine  a three-dimensional  universe  - bbott , 1884) . 

Similarly,  the  absence  of  a dimension  in  a program  will 
cause  a very  common  type  of  malfunction:  The  program 

does  its  simulation  perfectly;  it  just  does  not  simulate 
the  world  that  the  programmer  has  in  mind. 
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8.1.2  Parameters  of  Simulations 

The  Licklider  thesis  (1973)  is  that  a computer  program 
is  a description  (or  simulation)  of  a process  which  might 
occur  in  the  real,  outside  world.  The  present  authors 
have  added  that  maintenance  programmers  do  their  work 
within  the  constraints  of  a mental  "simulation"  of  the 
outside  world.  From  this  point  of  view,  it  is  useful 
to  list  some  basic  parameters  of  simulations  in  general; 
and  to  note  ways  that  they  differ  between  people  and 
programs . 

Parameters  include  (1)  the  number  of  variables  or 
dimensions  involved  in  the  simulation,  (2)  the  size  or 
capacity  of  the  memory  that  it  occupies,  (3)  the  fine- 
ness of  its  categorization  or  digitizing,  (4)  its 
capacity  for  interpolation  and  extrapolation,  and 
(5)  its  suceptibility  to  change. 


8.1. 2.1  Number  of  Variables 

An  engineer,  wanting  to  predict  the  performance  charac- 
teristics of  a proposed  airfoil,  may  request  the  use  of 
a computer  program.  The  program,  in  turn,  may  require 
data  which  give  the  density  of  the  air  at  various  alti- 
tudes. The  density  data  may  be  viewed  as  a one-variable 
simulation  of  the  world. 

If  one  were  concerned  about  the  performance  of  a pilot 
rather  than  an  airfoil,  a simulation  program  would  have 
to  represent  and  combine  the  effects  of  many  variables: 
air  density,  nutrition,  work  load,  muscular  strength, 
etc.  To  our  knowledge,  such  a program  does  not  exist. 

More  generally,  computer  programs  are  simulations  of 
few-dimensional  worlds.  These  are  "exercised"  in  great 
detail,  with  well-known  successes. 


( 
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People,  in  contrast,  are  properly  called  upon  to  make 
plans  which  include  many  different  aspects  of  reality. 
Efficient  reorganization  of  a clerical  office,  for 
example,  might  require  knowledge  of  the  talents  and 
personalities  of  the  clerks,  acquaintance  with  the  user 
level  documentation  of  computer  programs,  familiarity 
with  the  various  jobs  the  office  has  to  do,  awareness 
of  the  space  and  equipment  requirements,  some  feeling 
for  what  the  workers  will  and  will  not  tolerate,  and  so 
on. 


i 
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8 . 1 . 2 . 2 Memory  Capac ity 

The  simulation  must  be  stored  in  something.  One  normally 
thinks  of  this  something  as  being  a computer  memory. 
Certain  simulations  can  require  very  large  memories.  By 
the  standards  of  only  a few  years  ago,  computer  memories 
available  today  are  indeed  large. 

Turning  to  the  "size"  of  the  memory  in  which  a person 
develops  his  "simulation,"  the  situation  is  less  clear. 

A remarkable  fact,  which  has  been  elaborated  elsewhere 
(Overton,  1961) , is  that  estimates  of  the  memory  capacity 
of  the  human  brain  disagree  by  15  orders  of  magnitude: 
by  a factor  of  a trillion. 


8. 1.2. 3 "Granularity" 

The  Air  Force  once  supported  Melpar  in  the  building  of 
an  experimental  maze-running  machine  which  was  attached 
to  an  immobile  "learning  network"  (Carne,  1962) , (Using 
company  funds  at  another  corporation,  the  authors  de- 
veloped a "learning  machine"  which  was  similar,  but  which 
was  entirely  non-physical:  the  maze  and  machine  were 

both  simulated  in  a computer.)  As  the  Melpar  machine 
buzzed  around  in  a maze,  the  "learning  network"  built  up, 
within  itself,  a sort  of  model  of  the  maze.  The  model 
dealt  primarily  with  the  one  variable  of  azimuth,  or 
direction.  This  variable  was  split  into  four  cate- 
gories; that  is,  all  turns  were  right  angles.  In  other 
words,  the  system  simulated  an  imaginary  world  in  which 
45-degree  turns  did  not  exist. 

For  a digital  system,  all  variables  must  be  digitized  or 
categorized  in  some  way.  The  fineness  of  digitization 
determines  what  might  be  called  the  "granularity"  of  the 
simulation  or  "picture"  which  the  system  produces. 

Incidentally,  there  is  a relationship  between  size  of 
memory,  and  granularity.  Obviously,  finer  categoriza- 
tion and  smaller  granularity  call  for  the  simulation  of 
more  points  on  each  scale  or  variable;  and,  therefore, 
for  more  memory  storage. 

People,  like  the  maze  "learning  network,"  tend  to  be 
broad-category  systems.  Suppose  a person  is  asked  to 
make  absolute,  non-comparative  judgments  of  the  absolute 
magnitudes  of  variables  such  as  weights  and  noise  levels; 
he  tends  to  place  them  in  only  a few  broad  classifi- 
cations: "very  heavy,"  "medium,"  "fairly  quiet,"  etc. 

Digital  computers,  in  contrast,  can  usually  record  a 
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measurement  with  all  of  the  precision  with  which  it  can 
be  measured. 

Because  people  and  computers  use  different  "granulari- 
ties," a bug  developed  in  one  of  the  programs  for 
"learning."  At  one  point,  the  program  needed  to  choose 
at  random  among  several  possibilities.  To  make  the 
choice,  the  programmer  called  in  some  digits  which  he 
considered  insignificant  and  random:  round-off  error 

from  a previous  division.  He  had  the  program  refer  to 
these  digits  to  make  its  choice  (by  a procedure  like 
eliminating  the  first  half  of  the  possibilities  if  the 
first  digit  was  odd,  eliminating  the  next  quarter  if  the 
next  digit  was  odd,  and  so  on.) 

As  the  programmer  should  have  known,  however,  the 
computer  accumulated  and  erased  round-off  in  a systematic 
manner;  so  the  "random"  choices  were  not  really  random; 
and  the  lack  of  randomicity  was  sufficient  to  make  the 
program  malfunction. 


8. 1.2. 4 Power  of  Generalization 

Any  simulation  must  be  based  on  what  are  often  called 
"data  points;"  i.e.,  on  known  samples  of  relationships 
between  variables.  Typically  the  points  as  such  are 
never  seen  by  the  programmer;  instead,  he  uses  an 
equation  which  "fits"  the  points.  He  programs  the 
equations  (and  even  business  programs  can  be  viewed  as 
systems  of  discrete,  logical  equations)  and  then  goes 
away  happy. 

(In  some  systems,  the  program  itself  performs  operations 
which  are  the  logical  equivalent  of  fitting  equations 
to  the  data . ) 

Some  significant  decisions  are  hidden  behind  the  equations 
or  their  equivalent.  The  putative  equations  are  essen- 
tially mechanisms  for  interpolating  between,  and  extrapo- 
lating beyond,  data  points. 

(1)  How  far  shall  extrapolation  be  allowed?  At 
what  point  should  one  start  losing  confidence 
in  the  extrapolations? 

(2)  By  what  rules  should  interpolation  be  per- 
mitted, and  with  what  degree  of  confidence? 

(3)  Is  the  user  warned  of  extrapolations  and 
interpolations  which  may  not  be  accurate?  (No 
is  usually  the  answer.) 


87 


Less  precisely  speaking,  these  questions  ask:  What  is 

the  power  of  the  program  to  generalize?  And,  how  is 
this  power  reported  to  the  user? 

Programs,  of  course,  possess  whatever  degree  of  generali- 
zation power  that  happens  to  be  given  to  them.  People, 
in  contrast,  have  much  more  power  and  inclination  to 
generalize  than  they  may  realize.  A classic  book 
(Bartlett,  1932)  shows  that  throughout  life  people  tend 
to  substitute  extrapolations  and  interpolations  for 
"real"  memories,  and  to  confuse  the  two. 

People's  tendency  to  generalize — to  "fill  in  the  gaps" 
in  a situation — helps  account  for  at  least  one  common 
type  of  bug:  one  in  which  the  program  makes  a test  for 

a narrow  area,  whereas  the  programmer  has  a larger  area 
in  mind  ...  as  when  the  programmer  tells  the  program 
to  go  out  of  a loop  at  N - K,  while  he  means  N = K or 
greater.  Then,  if  the  incrementing  process  skips  over 
N = K (as  in  counting  by  two,  and  skipping  an  integer) , 
a bug  develops:  the  program  gets  trapped  in  the  loop. 


8. 1.2. 5 Susceptibility  to  Change 

From  a detached  and  academic  point  of  view,  a "simulated 
outside  world"  should  be  capable  of  self-improvement; 
it  should  change,  and  become  more  realistic,  as  more 
evidence  or  data  come  in.  In  practice,  of  course,  one 
normally  does  not  want  a computer  program  to  start 
changing  itself  in  any  independent  manner.  (A  payroll 
program  would  disturb  the  management  if  it  decided  to 
start  giving  raises  to  people.) 

People  do  change  their  "simulations"  as  time  and  events 
transpire.  Some  people  make  changes  more  readily  than 
others — they  require  less  evidence  before  modifying  their 
"view  of  reality."  Somewhat  surprisingly,  there  is  no 
evidence  that  susceptibility  to  change  (at  least  in 
some  areas)  has  any  correlation  with  differences  in 
intelligence  (Adorno  et  al,  1950).  The  present  authors 
speculate,  however, * ' tion 


ness  to  change  one's  view  of  "reality."  Therefore, 
research  in  this  area  might  contribute  to  more  efficient 
programmer  selection. 

Returning  to  the  computer  program  as  a simulation,  its 
susceptibility  to  change  by  the  maintenance  programmer, 
rather  than  by  itself,  should  of  course  be  high.  That 
is  simply  a re-statement  of  the  general  goal  of  this 
project;  and  the  detailed  ways  of  reaching  it  would 
trace  many  of  the  steps  of  this  and  preceding  projects. 


between  programming 


willing- 
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8.1.3  The  Embedding  of  Simulations 

Occasionally  managers  complain  that  some  programmers 
lack  "common  sense."  (An  example  was  a hospital  adminis- 
trator who  cited  a programmer  whose  program  displayed 
most  data  in  scientific  notation.  Hospital  clerical 
helpers,  who  "didn't  know  an  exponent  from  an  expletive," 
were  confused  to  find  dates  written  as 

2.5  x 101  OCT  1.969  x 103.) 

What  the  managers  seem  to  mean  by  "common  sense"  is  an 
accumulation  of  knowledge  about  the  real  world.  Common 
sense  is  shown  by  an  agreement  of  views:  If  the  user 

and  his  environment  are  viewed  in  the  same  way  by  the 
programmer  and  the  manager,  then  the  manager  says  the 
programmer  has  "common  sense." 

As  this  rather  cynical  definition  implies,  measurement 
of  common  sense  is  not  an  absolute  process:  It  depends 

on  who  is  doing  the  measuring.  Different  people  are  not 
working  with  exactly  the  same  simulations  of  reality. 

(From  the  user's  point  of  view,  the  programmer  and  his 
manager  may  both  lack  common  sense.) 

The  program  (according  to  Licklider)  simulates  a little 
bit  of  the  real  world  in  which  the  user  operates.  But 
it  is  a very,  very  detailed  simulation  of  that  little 
bit.  (It  says,  if  it  is  a payroll  program,  that  you 
eliminate  leading  zeroes  before  the  most  significant 
digit  in  writing  a paycheck.  And  it  specifies  all 
necessary  calculations  before  you  get  to  that  point.) 

On  the  other  hand,  the  user's  simulation  of  the  simu- 
lation is  usually  quite  attenuated.  (He  may  only  know 
that  you  put  time  cards  in,  and  you  get  paychecks  out.) 

In  general,  then,  there  is  a double  spectrum  of  simu- 
lations : 

(1)  The  program,  as  a simulation,  suffers  from 

more  and  more  attenuation  and  over-simplification 
as  it  is  represented  by  people  farther  and 
farther  from  the  original  programmer. 

(2)  The  user's  world,  and  his  need  for  modification 
of  the  program,  is  similarly  attenuated  as  one 
moves  from  the  user  to  the  programmer. 

And  at  every  point  the  program/simulation  is  embedded 
in  some  degree  of  simulation  of  the  user's  world  and 
needs . 
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8.1.4 


Implications  for  Maintenance 


"Work  on  a program,"  especially  in  maintenance  program- 
ming, includes  thinking  about  where  in  the  program  to 
do  the  most  detailed  work.  In  the  terminology  of  the 
previous  section,  work  on  a program  involves  manipulating 
a simulation  which  is  embedded  in  another  simulation: 
a simulation  of  a simulation  of  a small  part  of  the 
procedures  in  the  world,  embedded  in  a more  attenuated 
simulation  of  the  user's  world  in  which  those  procedures 
will  be  followed. 

In  these  terms,  the  difficulties  of  the  maintenance 
programmer  stem  from  these  causes: 

(1)  He  is  in  the  middle:  He  has  to  be  sufficiently 

"in  tune"  with  the  user's  simulations  to  in- 
corporate them  into  his  own — in  other  words, 

to  understand  the  user.  But  then  he  has  to 
turn  to  the  ultimate  simulation — the  program 
— and  show  that  he  understands  it  sufficiently 
to  change  it. 

In  larger  programming  organizations,  of  course, 
there  is  usually  some  kind  of  middleman — called 
analyst,  customer  engineer,  or  some  other  nice 
title — between  the  programmer  and  the  user. 

But  the  basic  problem  still  remains:  bringing 

two  "simulations,"  which  normally  suffer  from 
different  degrees  of  attenuation,  into  agree- 
ment with  each  other. 

(2)  The  maintenance  programmer  must  find  out  what 
variables  or  dimensions  he  can  ignore  in  the 
simulation/program  on  which  he  must  work.  He 
has  to  coordinate  his  modification  (or  mini- 
simulation) with  all  relevant  variables,  and 
with  none  of  the  irrelevant  ones.  And  he 
lacks  the  time  to  "exercise"  or  trace  through 
all  of  the  aspects  of  the  program  which  are 
not  relevant  to  his  modification. 


8. 1.4.1  Emphasis  on  Dimensions 

Given  these  causes  of  difficulties,  some  suggestions  can 
be  made  about  possible  ways  of  alleviating  them.  The 
first  calls  for  emphasis  on  dimensions  and  variables 
rather  than  on  calculations. 

Initial  program  design  should  be  organized  in  terms  of 
"variables  and  dimensions."  Broad  input  variables 


90 


should  be  specified  and  then  refined  down  to  the  level 
of  the  computing  environment  (in  the  COBOL  sense  of  the 
word) . Output  variables  should  similarly  be  worked 
backwards  to  the  computational  results  which  generate 
them. 

This  practice  would  obviously  make  it  easier  for  the 
maintenance  programmer  to  reject  the  variables  which 
were  irrelevant  to  his  modification.  Thus  he  could 
"compress"  the  simulation/program  into  a new  simulation 
which  would  be  simpler  but  still  contain  the  material 
he  needed. 

This  style  of  program  design  is  certainly  not  entirely 
new,  although  it  has  not  been  given  the  emphasis  which 
we  give  it  here.  The  major  difference  between  this 
practice  and  current  custom  would  lie  in  when  calcu- 
lations were  performed.  Insofar  as  possible , all  input 
variables  would  be  read  in,  and  stored  in  specified 
files,  before  any  calculations  were  performed  on  any  of 
these  data.  Also,  computational  routines  would  be 
designed  to  cope  with  blank  files — by  simply  reporting 
them  as  blank,  rather  than  by  generating  error  signals. 
Dummy  input  variables  might  even  be  provided,  so  that 
the  maintenance  programmer  could  use  them  to  add 
variables  at  a later  date. 

Similarly,  partially- reduced  data  would  be  stored  in 
derived  or  sub-variable  files,  and  these  would  be  filled 
(as  needed)  before  further  calculations  were  performed. 

Re-combining  of  files  would  be  done  as  output  was 
approached. 

This  practice  would  resemble  the  currently-popular  "top- 
down"  programming,  except  that  there  the  emphasis  is 
on  building  a hierarchy  of  calculation.  Here  the 
emphasis  would  be  on  building  a hierarchy  of  variables 
and  variable  results  of  calculations.  Here,  also, 
instead  of  one  pyramid  of  hierarchy,  there  would  be  a 
double  pyramid  between  input  and  output. 

As  an  example  of  this  approach,  consider  a hypothetical 
program  for  use  in  the  mining  industry.  Given  assay 
results  from  samples  for  a prospective  mining  site,  the 
program  will  do  trade-off  studies  to  help  decide  how  much 
to  concentrate  the  ore  on-site  (with  more  expense  for 
greater  concentration) , versus  shipping  less  concentrated 
ore  (at  greater  shipping  expense)  to  a larger  and  more 
efficient  permanent  mill. 
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One  approach  would  be  to  proceed  with  the  following 
steps:  The  programmer  would  generally  flow  chart  the 

heart  of  the  program:  the  algorithms  for  doing  the 

trade-off  calculations.  Then  he  would  work  down  from 
this  heart,  specifying  the  supporting  algorithms,  which 
would  be  tied  in  to  the  data  input  and  output  routines. 

The  approach  advocated  here  would  be  to  decide  first 
on  the  basic  dimensions  of  the  simulations.  One  dimension 
might  be  a mineral;  variables  to  be  read  along  that 
dimension  would  include  its  concentration  in  the  sample, 
its  price,  and  possibly  others.  The  provision  would 
be  made  for  derived  variables;  value  of  the  mineral  per 
ton  of  ore  would  be  one  derived  variable,  and  provision 
would  be  made  for  others,  through  appropriate  file 
reservations . 

Complementing  the  "tree  structure"  of  input  files  would 
be  a corresponding  "root  structure"  of  output  variables. 
The  user's  interests  include  investments,  returns,  and 
time.  These  and  other  variables  might  be  sandwiched 
between  basic  output  files  such  as  cumulative  return  on 
investment,  and  more  detailed  intermediary  files  such 
as  equipment  depreciation  schedules. 

The  heart  of  the  program — the  algorithms  for  doing  the 
trade-off  calculations — would  come  last.  Its  functions, 
in  terms  of  comparing  files  and  results,  might  be  dis- 
tributed among  smaller  modules  than  would  be  the  case 
if  it  had  been  used  as  the  point  of  departure. 

If  a bug  were  later  found  in  (say)  the  calculation  of 
copper  values,  or  if  new  technology  dictated  a change 
in  the  costs  of  concentrations,  it  might  be  easy  for  the 
maintenance  programmer,  under  this  approach,  to 
attenuate  the  overall  simulation/program  into  only  those 
portions  which  he  needed  to  modify. 


8 . 1 . 4 . 2 Transformation-Oriented  Groups 

A suggestion  which  logically  follows,  under  the  approach 
oriented  here,  is  this: 

Conceptual  groups  should  include — but  not  be 
limited  to — computational  routines  for  performing 
one  and  only  one  transformation  on  one  variable  or 
sub- variable. 

Higher-level  groups  or  modules  could  then  represent 
sets  of  related  transformations  of  variables. 
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Referring  to  the  mining  example,  one  conceptual  group 
might  do  nothing  more  than  multiply  copper  prices  by 
copper  concentrations,  to  get  the  value  of  copper  per 
ton  of  ore. 

This  is  not  entirely  a new  suggestion  either.  It  is 
similar  to  the  practice  in  a large  maintenance  project 
which  sought  "self-documentation"  through  the  placement 
of  commentary  with  "each  little  function."  It  also  re- 
sembles the  practice  (which  seemed  very  successful)  at 
Copley  Computer  Systems,  Inc.:  Programs  were  built  of 

"sections,"  each  of  which  performed  one  and  only  one 
function.  "Sections"  were  short,  ranging  from  only  two 
lines  in  length,  through  a mode  of  a small  number,  to  a 
maximum  of  about  40  lines  each. 

It  has  previously  been  observed  that  there  are  different 
"representations"  of  the  program:  the  program  itself, 

its  commentary,  other  programmer  documentation,  user 
documentation,  etc.  (The  term  "representation"  comes 
from  the  study  of  ways  in  which  technical  articles  can 
be  abstracted.  The  article  itself  is  one  representation, 
its  title  is  another;  two  different  abstracts  each  writ- 
ten for  a different  purpose,  could  be  two  other  repre- 
sentations. 

It  was  also  observed  that  there  are  interactions  between 
the  programmer,  the  program,  and  various  representations 
of  the  program.  Obviously,  the  interactions  are  best 
when  the  maintenance  programmer  can  work  with  a repre- 
sentation which  is  tailored  to  his  purposes. 

The  above  two  suggested  practices  would  greatly  help  a 
programmer  to  create  a representation  of  the  program 
which  was  tailored  to  his  purposes.  He  could  do  so  by 
eliminating  irrelevant  variables  and  dimensions,  and  by 
concentrating  on  the  "sections"  whose  functions  he  needed 
to  change. 

These  practices  represent  a somewhat  different  philosophy 
than  that  which  seems  to  be  behind  most  of  the  calls  for 
top-down  programming.  The  difference  in  philosophy  can 
be  illustrated  by  analogies  with  maps  and  geometric 
figures . 

In  philosophy,  most  top-down  advocates  seem  to  envision 
program  development  as  analogous  to  changing  scale  on  a 
map.  The  top-level  description  is  like  a small  map  of 
the  United  States,  on  which  many  details  are  omitted. 

As  one  moves  down  to  the  coding  level,  details  are  added 
to  the  map,  but  its  total  configuration  remains 
essentially  unchanged. 
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The  present  approach  views  different  representations  of 
the  program  as  analogous  to  projections  of  geometric 
figures  into  different  universes.  A sphere  from  a 
three-dimensional  universe  becomes  a circle  when  it  is 
projected  into  a two-dimensional  universe;  it  becomes  a 
line  when  projected  into  a one-dimensional  universe. 

It  does  not  just  change  scale;  it  changes  form. 

The  maintenance  programmer  needs  to  work  in  as  limited 
a universe  as  possible;  modifications  are  made  most 
efficiently  when  they  can  be  made  simply.  For  this 
reason,  the  philosophy  of  making  it  easy  "to  yank  out 
dimensions"  would  also  make  it  easier  for  the  mainte- 
nance programmer  to  "zero  in"  on  the  places  to  make 
coding  changes . 

Finally,  one  should  not  give  up  other  conceptual  groups 
which  programmers  have  found  useful.  Not  all  groups, 
which  helped  the  programmers  in  these  studies,  were 
based  on  "each  little  function."  The  philosophy  of 
"yanking  out  dimensions"  is  an  approach  to  enhancing 
maintainability  which  does  not  rule  out  the  use  of  other 
techniques  and  aids. 


8. 1.4. 3 Function  and  Variable  Displays 

This  approach  also  carries  implications  regarding  the 
kind  of  displays  that  are  likely  to  be  most  useful  for 
maintenance  programmers  at  graphics  terminals. 

Terminal  operating  systems  should  facilitate  displays 
of  (1)  unitary  functions  which  transform  variables,  and 
(2)  the  resulting,  transformed  variables. 

In  view  of  the  apparent  preference  of  many  people  for 
visual  analogs,  the  transformed  variables  might,  wherever 
feasible,  be  available  in  analog  form. 

In  terms  of  this  dimensional  approach,  operating  systems 
like  that  just  advocated  would  make  it  easier  for  pro- 
grammers to  simplify,  or  compress  the  picture,  which 
they  apparently  like  to  do  when  they  are  puzzled. 

More  basically,  it  would  also  facilitate  the  making  of 
the  comparisons  which  maintenance  programmers  frequently 
have  to  make:  comparison  of  one  version  of  a short 

function  with  a later  version  of  the  same  functional 
unit;  and  comparison  of  a functional  unit  with  its 
effect  on  a dependent  variable.  The  ease  and  speed  of 
these  comparisons  has  much  to  do  with  the  speed  at  which 
maintenance  programming  progresses. 
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8.2  Recommended  Research  Projects 


8.2.1  Computer  Aided  Software  Maintenance 
Terminal  Systems 

In  a study  of  the  Fundamental  Factors  Underlying  Soft- 
ware Maintenance  Problems,  ESD-TR-72-121  (Overton  et  al, 
1971)  two  Research  Plans  were  presented;  one  of  higher 
priority,  shorter  range,  moderate  cost  nature;  and  the 
other  of  lower  priority,  longer  range  and  of  greater 
cost  nature.  With  the  possible  exception  of  the  Termi- 
nal Arrangements  Task  all  the  other  studies  and  experi- 
mentation to  date  outlined  in  ESD-TR-72-121,  ESD-TR-73-125 
and  the  current  effort  have  been  tasks  emanating  from  the 
higher  priority  research  plan.  In  the  Terminal  Arrange- 
ments Study,  effort  was  begun  to  look  at  the  overall 
environmental  aspects  of  interaction  between  a programmer's 
sensory  perception  and  computing  system  input/output 
equipment,  including  graphic  terminals. 

One  of  the  research  projects  outlined  in  the  longer  range 
plan  was  the  establishment  of  a Microcosmic  Test  Bed 
to  more  objectively  study  the  use  of  the  interactions 
among  graphic  terminals,  structured  documentation  and 
hard  copy.  The  Terminal  Arrangements  Study  results  and 
interpretations  (in  Secs.  3 and  4)  indicate  that  there 
is  need  for  greater  integration  of  the  sensory  informa- 
tion inputs  (and  outputs)  between  the  maintenance  pro- 
grammer and  the  graphics  console.  Of  the  independent 
variables  identified  (in  Sec.  2. 2. 3.1),  the  experimenta- 
tion was  able  to  cover  only  those  of  program  complexity 
and  modularity.  The  Terminal  Arrangements  Study  pro- 
duced a wealth  of  possibilities  for  improvement  in 
software  maintenance  utilizing  graphic  terminals. How- 
ever, the  results  were  based  as  much  on  field  observa- 
tion as  on  controlled,  scientific  experimentation. 

Therefore  it  is  recommended  that  a Test  Bed  be  established 
to  confirm  and  make  practical  applications  of  these 
results,  and  to  study  the  effects  of  other  independent 
variables  and  possible  maintenance  aids  in  graphic 
terminal  systems.  It  is  suggested  that  the  ARPA  net- 
work be  considered  for  the  research  test  bed. 

TASK  1.  Software  Maintenance  Terminal  System. 

Perform  a study  to  establish  optimum  graphic 
terminal  arrangements  for  computer-aided  soft- 
ware maintenance.  The  effort  would  include: 

(1)  Select  a test  bed  for  experimentation.  Make 

arrangements  with  existing  selected  time-sharing 
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network  user  (university,  government,  govern- 
ment sponsored)  services  and  utilization  of 
graphic  terminal  system  as  a test  bed.  Augment 
test  bed  as  necessary  to  enable  execution  of 
objective  experimentation. 

(2)  Develop  Test  Plan  for  experimentation  with  sig- 
nificant independent  variables.  Test  Plan 
should  be  for  at  least  two  series  of  experi- 
ments, with  a review  and  revision  period  between 
each  series  of  tests. 

(3)  Execute  initial  experiments.  Reword  sensory 
data  and  experimental  results.  Perform 
analysis  and  present  objective  evaluation. 

(4)  Revise  Test  Plan  and  conduct  next  series  of 
experiments.  Reword  sensory  data  and  experi- 
mental results.  Perform  analysis. 

(5)  Write  a report  of  results,  specifying  and  re- 
commending design  guidelines  for  development 
of  integrated  computer  Terminal  Systems  which 
are  efficient  for  computer  aided  software 
maintenance. 
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8.2.2  Computer-Aided  Software  Maintenance 
Support  Systems 


8. 2. 2.1  Automated  Maintainability  Guideline 
Development 

A methodology  has  been  developed  for  defining  useful 
guidelines,  developing  test  procedures  and  conducting 
experiments  to  establish  within  reasonable  doubt  guide- 
lines which  can  be  automated  and  are  effective  in 
improving  software  maintainability.  This  methodology 
should  now  be  applied  to  the  study  and  verification  of 
those  guidelines  suggested  in  ESD  TR- 72-121  (Overton  et 
al,  1971)  and  ESD  TR -73-125  (Overton  et  al  1973) . The 
following  tasks  are,  as  a minimum  recommended. 

TASK  2.  Conceptual  Groupings  for  COBOL  (GP-C) . 
Perform  a study  of  conceptual  groupings  in 
COBOL  and  their  applications  to  the  enhance- 
ment of  the  efficiency  of  maintenance  pro- 
gramming. The  effort  would  include: 

(1)  Select  the  subset  of  the  COBOL  language  and 
determining  the  corresponding  conceptual 
groupings . 

(2)  Plan  observations  of  the  use  of  groupings  to 
obtain  the  most  valid  possible  data. 

(3)  Design,  Program  and  Debug  a computer  program 
which  will  be  a post-processor  to  a COBOL 
compiler  to  create  conceptual  groupings  of  a 
source  COBOL  program. 

(4)  Observe  the  usage  of  groupings,  modify  com- 
pilers to  distinguish  such  groupings,  and 
observe  and  collect  data  on  the  value  to 
maintenance  programmers  of  such  modifications, 
as  a basis  for  later  recommendations. 

(5)  Summarize  and  analyze  the  observations  just 
described,  to  reach  the  most  valid  possible 
conclusions . 

(6)  Write  a report  of  the  results,  clearly  stating 
recommendations  of  value  to  maintenance  pro- 
gramming. Deliver  the  prototype  COBOL  Con- 
ceptual Groupings  Program  (GP-C) , including 
programming  documentation  and  operating  in- 
structions . 
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TASK  3.  Developing  Automated  Guidelines.  Perform 
a study  to  derive  automated  procedures  for, 
as  a minimum,  the  DISTANCE  and  the  NOTES 
guidelines.  The  effort  would  include: 

(1)  Review  existing  analyses  of  the  fundamental  fac- 
tors which  inhibit  program  maintenance  and  the 
corresponding  maintainability  guidelines,  and 
select  those  guidelines  the  objective  measures  of 
which  will  significantly  enhance  computer 

aided  software  maintenance. 

(2)  Develop  methods  of  measuring  the  effectiveness 
of  at  least  the  DISTANCE  and  NOTES  guideline, 
and  outline  a program  of  experiments  to  verify 
the  applicability  of  the  derived  measures. 

(3)  Execute  the  planned  experiments  in  the  approved 
test  plan  using  the  largest  test  sample  size 

as  practicable  within  the  target  costs  involved. 

(4)  Based  on  an  analysis  of  the  data  from  the 
initial  experiments,  verify  the  effectiveness 
of  the  measures,  modifying  the  measures  and 
test  procedures  as  necessary,  and  verify  the 
revised  measures  of  maintainability. 

(5)  Recommend  those  guidelines,  the  measures  for 
which  can  be  automated  through  computer  assisted 
software . 

(6)  Prepare  a report  summarizing  the  research 
methodology  used  to  develop  automated  guide- 
lines for  computer  assisted  software  mainte- 
nance, together  with  the  results  of  the  test 
experimentation  to  verify  and  select  the 
corresponding  measures. 


8.2. 2. 2 Automated  Program  Error  Search 

A recurrent  theme  throughout  the  interview  and  observation 
sessions  of  the  Terminal  Arrangements  Study  task  was 
the  maintenance  programmer's  need  for  better  automated 
procedures  to  assist  in  the  software  maintenance  effort. 
The  potehtial  use  of  decision  theory  as  an  aid  in  helping 
locate  where  an  error  is  occurring  or  where  a program 
change  should  be  made  was  outlined  in  ESD  TR-73-125 
(Overton  et  al,  1973) . It  is  recommended  that  the 
following  effort  be  undertaken  to  develop  and  verify 
this  effective  methodology  utilizing  graphic  terminals. 
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TASK  4 . Computer  Aided  Software  Error  Search 

(CASES)  System.  Perform  the  design  and  develop- 
ment of  a computer  program  error  search  system 
utilizing  decision  theory  as  a computer 
assisted  software  maintainability  aid.  The 
effort  would  include: 

(1)  Collect  the  background  information  necessary 
to  plan,  in  terms  of  general  flow  charts,  the 
proposed  system.  Review  the  relevant  litera- 
ture on  different  statistical  techniques  in 
decision  theory,  and  on  the  classification  of 
bugs.  Develop  a usable,  realistic,  expandable 
nomenclature  of  bugs.  Design  note-  and 
history-taking  routines.  Design  the  statis- 
tical decision  routines.  Integrate  the  plans 
into  a set  of  system  flow  charts.  Insure  that 
specifications,  descriptions,  and  documen- 
tation are  compatible  with  software  maintain- 
ability and  can  make  effective  use  of  computer 
assisted  software  maintenance  software  systems. 

(2)  Develop  and  evaluate  a preliminary  System. 

Select  a test  bed  in  coordination  with  in- 
terested users,  program  a preliminary  version 
of  the  system  and  evaluate  and  refine  the 
design.  Design  and  conduct  experiments  to 
bring  out  good  and  bad  features,  and  data  on 
these  features,  in  the  preliminary  system. 

Design  a refined  and  more  generally  usable 
version  of  the  system  in  terms  of  flow  charts. 

(3)  Implement  a Prototype  System.  Perform  a test 
implementation  of  the  prototype  system  on  a 
selected  time-sharing  network.  Following  the 
design  in  the  flow  charts  from  (2)  and  within 
the  constraints  of  the  time-sharing  network, 
etc.,  reprogram  the  CASES  system  in  prototype 
form.  Install  and  in  accordance  with 
reasonable  standards,  debug  the  CASES 
system,  making  it  available  to  interested 
users. 

(4)  Create  a Final  Report  detailing  the  background 
and  planning  of  the  efficient  debugging 
decision  system  and  the  lessons  thus  far 
learned  in  taking  advantage  of  it  to  improve 
the  efficiency  of  maintenance  programming. 


/ 
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8. 2. 2.3  Computer  Aided  Software  Maintenance 
Metrics  System 

It  appears  desirable  at  this  stage  to  begin  the  design 
and  development  of  an  overall  system  structure  of  a 
computer  assisted  software  maintenance  system  utilizing 
graphic  terminals.  The  test  bed  for  such  a development 
should  be  some  user  time-sharing  network  of  interest 
such  as  the  ARPA  or  WIMMEX  networks. 

The  envisioned  graphics  system  will  encompass  both 
computer  assisted  techniques  of  software  maintenance 
evaluation  while  new  systems  are  under  development  and 
of  program  analysis,  change  determination,  and  error 
discovery,  for  systems  undergoing  test  and  change. 

The  approach  taken  is  to  develop  a conceptual  structure 
of  the  overall  interactive  graphics  system,  implementing 
selected  maintainability  guidelines  in  the  form  of 
metrics  sub-program  modules  as  their  definition  and 
quantization  are  established  and  verified.  (See  Tasks 
2 , 3 , and  4 . ) 

By  maintaining  a top-down  structure  to  the  metrics  execu- 
tive system,  and  a modularized  approach  to  the  metrics 
sub-programs,  a highly  effective  graphics  system  can  be 
evolved  over  time.  The  system  can  be  revised  and  improved 
to  better  assist  the  maintenance  programmer  as  more 
techniques  are  identified  and  quantized. 

TASK  5.  Develop  Maintainability  Metrics  System. 

Perform  the  design  and  development  of  a Computer- 
Aided  Software  Maintenance  Metrics  System.  The 
effort  would  include: 

(1)  Design  the  structure  of  a computer  aided 
maintenance  metrics  system.  The  system  shall 
be  designed  to  operate  on  an  inter-active 
basis,  capable  of  being  interfaced  with  a 
variety  of  graphics  consoles  and  computer  tele- 
communications systems.  The  program  design 
shall  be  modular  and  expansible  such  that 
measures  of  maintainability  guidelines  can  be 
added  to  the  system  as  the  measures  are  defined 
and  successfully  verified. 

(2)  Program  and  test  the  necessary  portions  of  the 
Metrics  System  Program,  and  the  Metrics  Modules 
on  an  inter-active  time-sharing  system  utilizing 
a graphics  terminal. 
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(3)  Test  the  prototype  Metrics  System,  including 
the  groupings,  DISTANCE,  NOTES,  and  other 
selected  maintainability  guideline  sub-programs 
on  an  interactive  time-sharing  system  utilizing 
a graphics  terminal . The  prototype  Metrics 
System  will  be  implemented  in  such  a manner  as 
to  be  transferable  to  an  AFSC  designated 
computer  system. 

(4)  Prepare  a report  summarizing  the  prototype 
Metrics  System  design  and  implementation 
together  with  results  of  the  test  experimen- 
tations. Prepare  program  documentation  and 
operating  instructions  for  the  prototype 
computer  software. 
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8.2.3  Dimensional  Approach  to  Maintainability 

The  maintenance  programmer  has  to  search  for  the  exact 
parts  of  the  program  in  which  he  should  make  changes. 
There  are  indications  that  the  search  is  facilitated  if 
the  program  can  be  viewed  as  a simulation  and  if  the 
simulation  can  easily  be  compressed  into  various  simpler 
forms  by  the  removal  of  dimensions  or  variables.  Also, 
explicit  identification  of  dimensions  may  prevent  the 
errors  which  are  often  caused  by  unwarranted  implicit 
assumptions. 

TASK  6.  Dimensional  Structures  for  Software 

Maintainability.  The  dimensional  approach  to 
program  development  would  include  the  following 
tasks . 

(1)  Design  computational  routines  able  to  operate 
on  null  or  deleted  dimensions.  Develop  other 
requirements  for  dimensional  structures. 

(2)  Detail  the  approach  sufficiently  to  specify  its 
differences  from  current  practices  and  to 
defend  its  input  on  program  development  costs. 

(3)  Write  simple  programs  illustrating  the  approach. 

(4)  Conduct  experiments  using  other  programmers  to 
modify  the  dimensional  structured  programs  to 
evaluate  the  gains  in  maintainability  as 
compared  to  current  approaches  such  as 
modularity  and  structured  programming. 

(5)  Create  a final  report  outlining  the  preliminary 
findings  as  to  benefits  and  efficiencies  gained 
in  software  maintainability  with  the  dimensional 
approach . 
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APPENDIX  A 


LITERATURE  EXTRACTS 


This  project  included  a literature  review.  More  than 
two  hundred  potentially  relevant  reports  and  articles 
were  reviewed,  and  approximately  75  were  copied  or  filed. 
Prom  those  articles,  some  "quotable  quotes"  were  selected. 
They  are  presented  herein. 

Since  comments  on  the  literature  have  been  made,  where 
appropriate,  in  the  body  of  the  Final  Report,  the  liter- 
ature extracts  are  presented  here  in  a neutral  mode, 
without  any  evaluative  comments. 


Abrams,  Marshall  D.  "Remote  Computing:  the  Adminis- 

trative Side."  Computer  Decisions,  October  1973. 

"All  users  will  have  questions.  Their  questions 
may  be  answered  at  many  levels.  In  fact,  when  a 
question  is  first  asked,  the  inquirer  may  not  know 
what  level  of  response  he  requires." 

"...  it  should  be  remembered  that  any  exchange 
between  two  parties  rapidly  degrades  to  the  level 
of  understanding  of  the  lesser  party." 

"...  computer  centers  have  discovered  that 
users  cannot  be  permitted  free  access  to  systems 
programmers.  The  systems  programmers  could  have 
all  their  time  absorbed  in  answering  trivial 
questions.  But  some  users'  questions  will  have  to 
get  through  to  the  systems  staff;  this  may  be  the 
staff's  only  feedback,  or  they  may  be  the  only 
people  competent  to  answer  the  question." 


Baker,  F.T.  "System  Quality  through  Structured  Pro- 
gramming." AFIPS,  1972. 

"...  the  Team  operates  in  a highly  disciplined 
fashion  using  principles  of  structured  programming 
described  by  Dijkstra  and  formalized  by  Mills." 

"Although  no  statistics  on  number  of  errors  or 
number  of  runs  per  module  were  kept,  it  was  apparent 
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from  a qualitative  standpoint  that  both  were  sig- 
nificantly reduced  when  compared  to  similar 
systems  on  which  team  members  had  previously 
worked . " 

"The  program  library  system  used  was  also  a major 
factor  in  improving  quality.  Ensuring  that  up-to- 
date  versions  of  programs  and  data  were  always 
available  reduced  problems  frequently  encountered 
due  to  use  of  obsolete  versions.  For  instance, 
when  programmers  were  ready  to  use  an  interface, 
they  could  directly  include  the  appropriate 
declarations  into  their  code  instead  of  writing 
their  own  version.  When  the  interface  changed,  it 
was  only  necessary  to  recompile  to  incorporate  a 
new  version  into  all  affected  programs.  In 
addition  to  reducing  interface  problems,  the  library 
system  facilitated  study  of  code  to  allow  one  pro- 
grammer to  adapt  an  approach  used  by  another  in- 
stead of  re-creating  it.  Most  importantly,  it 
permitted  the  ready  review  and  criticism  of  code 
by  others  as  described  above.  As  a side  benefit, 
the  availability  of  all  this  information  in  usable 
form  reduced  the  need  to  get  it  verbally  and  thus 
further  reduced  errors  due  to  distraction  or 
interruption . " 

"This  project  has  suggested  two  areas  in  which 
further  work  needs  to  be  done.  First,  it  may  not 
always  be  possible  to  follow  a strictly  top-down 
approach  in  development  of  a large  programming 
system.  If  a system  organization,  viewed  as  a tree 
structure,  is  narrow  and  tall,  then  a pure  top- 
down  approach  may  take  too  much  elapsed  time  to  be 
practical.  Second,  a more  rigorous  approach  to 
code  review  needs  to  be  developed.  In  retrospect, 
a number  of  the  problems  encountered  in  the  Data 
Entry  Edit  Subsystem  after  delivery  were  of  such  a 
nature  that  they  would  probably  have  been  caught 
earlier  if  all  the  code  had  been  read. " 


Berner,  R.W.  "Manageable  Software  Engineering."  Software 
Engineering,  1970.  (Quoted  in  Computing  Reviews,  May 
1971.) 

Subsection  VIII. 3. 3 ("How  Should  Design  and  Imple- 
mentation Be  Partitioned?")  provides  opportunity 
for  the  author  to  state  his  feeling  that  the  three 
phases  of  programming — system  design,  design  of  a 
routine,  and  coding — are  best  done  by  the  same 
individual;  this  is  a 180  degree  reversal  of  the 
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usual  rule  of  thumb — have  the  three  phases  of  pro- 
gramming done  by  separate  individuals.  His  well- 
justified  conclusion  is  that,  except  for  small  jobs, 
the  entire  project  is  best  handled  by  the  same 
person.  Equating  'servicing'  with  program  mainte- 
nance, for  this  job,  the  author  rejects  'trainees' 
or  'experienced  support  personnel'  in  favor  of  the 
programmer  who  initially  built  or  modified  the 
software  (called  the  'originator').  'If  he  con- 
siders it  a trap,  let  him  know  that  nothing  but 
excellent  and  self-sustaining  documentation  will 
release  him  . . . . ' " 


Blee,  M.  "Modular  Programming — Innovation  or  Common 
Sense?"  Data  Systems,  February  1969. 

This  article  discusses  three  techniques  which 
differ  considerably  although  all  can  be  called 
"modular  programming"  in  that  they  involve  dividing 
a program  into  self-contained  modules. 


Brooks,  R.  Ruven.  A Model  of  Code-Writing  Behavior  in 
Computer  Programming^  Dissertation,  Carnegie-Mellon 
University,  1974 . 

"The  theory  consists  of  three  basic  processes; 
understanding,  planning,  and  coding.  While  these 
processes  are  named  in  the  order  in  which  they  will 
be  discussed  and  in  which  they  initially  take 
place,  in  most  situations  they  actually  behave  more 
like  co-routines,  with  each  processes  calling  on 
and  being  called  by  the  others . 

"Understanding 

"A  necessary  prerequisite  for  a problem-solver  to 
begin  work  is  that  he  have  some  understanding  of 
the  problem.  By  this  is  meant  that  he  has  built 
up  internal  representations  of  the  basic  elements 
that  the  problem  deals  with  and  their  properties, 
of  the  initial  state  of  these  elements,  and  of  the 
desired  final  state,  the  goal.  He  must  also  have 
one  or  more  operators  which  he  can  apply,  appro- 
priately, to  transform  the  initial  state. 

"The  information  from  which  these  internal  repre- 
sentations and  operators  are  built  may  come  from  a 
variety  of  sources.  Some  of  the  sources  will  be 
internal,  such  as  knowledge  of  the  problem-solving 
situation  and  general  "world"  knowledge.  Others  of 
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these  sources  will  be  external,  for  example,  the 
problem  directions  or  the  set  of  general  directions 
if  the  problem  is  part  of  a larger  problem  set." 

"Not  surprisingly,  evidence  of  an  understanding 
processes,  in  the  form  of  alternation  between 
reading  directions  and  reasoning  about  what  they 
say,  is  also  seen  in  records  of  behavior  in  pro- 
gramming problems." 

"Planning 

"The  type  of  plan  produced  by  this  intermediate 
process  is  an  algorithm  for  solving  the  programming 
problem;  it  consists  of  specifications  of  the  way 
in  which  information  from  the  real  world  is  to  be 
represented  within  the  program  and  of  the  operations 
to  be  performed  on  these  representations  in  order 
to  achieve  the  desired  effects  of  the  program. 

These  algorithms  are  used  as  schemas  or  templates 
to  guide  the  writing  of  the  actual  code." 

"The  content  of  a plan  is  probably  independent  of 
the  language  in  which  the  program  is  to  be  written. 
The  basis  for  this  assertion  is  partly  a subjective 
one,  the  introspective  reports  of  many  programmers 
that  they  are  able  to  think  about  solutions  to 
problems  without  knowing  the  language  that  the 
problem  will  be  written  in.  Reinforcing  the  sub- 
jective evidence  is  the  informal  observation  that, 
having  written  a program  in  one  language,  it  is 
easier  to  write  it  again  in  a second  language,  pro- 
vided that  both  languages  have  similar  operators 
and  data  types;  if  the  experiment  is  arranged  in 
such  a way  that  a direct,  language-to-language  re- 
coding is  impossible,  what  must  be  carried  over 
between  the  two  situations  is  the  algorith — i.e., 
the  plan. 

"While  the  content  of  a plan  is  independent  of  the 
programming  language  it  will  eventually  be  imple- 
mented in,  the  choice  of  a particular  plan  is 
clearly  made  with  a specific  programming  language 
in  mind.  Programmers  using  FORTRAN  do  not  usually 
select  plans  which  involve  list  structures,  nor  do 
LISP  programmers  customarily  set  up  their  programs 
to  use  fixed- format , record  input.  If  the  oppor- 
tunity exists,  plans  will  be  selected  which  are 
compatible  with  the  language  in  which  the  program 
is  to  be  written." 
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"Planning  does  not  take  place  as  a single  operation; 
instead,  an  iteration  occurs  in  which  each  plan 
that  is  created  serves  as  input  for  the  next 
cycles.  Each  cycle  refines  the  plan  and  makes  it 
more  detailed.  The  terminating  condition  for  the 
iteration  is  that  some — reasonably  large — part  of 
the  plan  is  sufficiently  detailed  so  that  the  pro- 
grammer feels  that  he  knows  how  to  translate  it 
into  code;  at  that  point  the  final  process  in  the 
writing  of  programs,  coding,  takes  over.  The 
coding  process  operates  on  a piece  or  part  of  a 
plan  until  either  code  is  produced  or  some  cri- 
terion is  met  which  causes  the  coding  process  to 
report  failure;  when  failure  occurs  information  is 
passed  back  to  the  planning  process  which  again 
attempts  to  produce  a codeable  plan." 

"In  many,  if  not  most,  programming  problems, 
planning  takes  place  extremely  rapidly  with  little 
evidence  of  any  kind  of  problem-solving  activity. 
This  suggests  that  what  takes  place  is  basically  a 
match  between  characteristics  of  the  current 
problem  and  the  invoking  requirements  of  a stored 
plan;  the  same  mechanism  might  also  account  for 
cases  which  require  a simple  piecing  together  of 
parts  of  plans.  In  turn,  this  recognition 
mechanism  also  implies  the  existence  of  mechanisms 
for  extracting  characteristics  from  current 
problems  and  mechanisms  for  abstracting  plans  from 
solved  problems." 

"While  the  recognition  system  will  probably  take 
care  of  the  overwhelming  majority  of  cases,  still 
other  mechanisms  will  be  necessary  for  the  re- 
maining cases  in  which  a stored  plan  could  not  be 
used.  These  might  be  divided  into  two  broad, 
general  classes:  those  which  use  programming 

knowledge  and  those  which  use  knowledge  from  the 
real-world  problem  domain  for  which  the  program  is 
being  written.  In  the  former  are  included  patching 
and  re-arranging  existing  plans;  generalizing 
from  examples;  and  the  use  of  diagrams  or  drawings. 
In  the  latter  are  included  all  those  situations  in 
which  the  programmer  goes  outside  the  programming 
domain  and  uses  knowledge  about  the  intended  use 
of  the  program,  relationships  among  the  data,  etc. 
to  solve  the  problem;  an  example  might  be  use  of 
knowledge  about  a company's  accounting  policies  to 
come  up  with  a plan  for  writing  a payroll  program." 
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"Coding 

"The  third  of  three  processes  in  the  theory  is 
coding.  For  human  programmers,  the  basic  cycle  for 
the  generation  of  code  consists  of  using  the  plan 
to  select  and  write  a piece  of  code,  assigning  an 
effect  or  action  to  the  code  that  has  been  written, 
and  comparing  the  effect  or  action  to  the  stipu- 
lations of  the  plan.  The  results  of  this  compari- 
son are  used  to  select  and  write  more  code  or  to 
change  the  code  that  has  been  written;  in  turn,  an 
effect  is  assigned  to  this  new  code  which  is  compared 
to  the  plan.  This  cycle  continues  until  the 
cumulative  effect  of  the  code  meets  the  require- 
ments of  the  plan  or  until  some  condition,  such  as 
effort  expenditure,  is  met  which  indicates  that  the 
piece  of  plan  is  not  codeable. 

"The  effects  that  are  assigned  to  code  are  based 
on  the  differentiations  among  the  data  that  the 
program  must  actually  make  in  order  to  accomplish 
its  purpose.  Consider  as  an  example  a program  for 
printing  all  the  odd  numbers  in  a set  of  integers; 
the  program  must  differentiate  between  odd  and  even 
numbers  in  order  to  perform  this  task.  An  effect 
that  could  be  assigned  to  a line  of  code  in  this 
program  might  be  'if  the  number  is  odd,  this 
branches  to  statement  50 , ' a statement  which  uses 
the  information  about  the  odd-even  distinction. 

The  cumulative  result  of  assigning  this  kind  of 
effect  to  each  line  in  a whole  segment  of  code  is 
to  execute  the  code  with  symbols  such  as  "odd 
number"  replacing  the  real  data;  hence  the  whole 
process  has  been  named  "symbolic  execution." 

"After  the  basic  cycle  has  generated  a sufficient 
amount  of  code,  the  entire  piece  of  code  may  be 
symbolically  executed  several  times  more.  This  may 
take  place  for  one  of  two  reasons.  The  first  is 
to  check  the  code  that  has  been  written  to  insure 
that  there  are  no  inconsistancies  between  its  actual 
effects  and  the  desired  ones.  The  second  reason 
is  that  there  is  no  look-ahead  in  the  basic 
generation  to  insure  that  all  necessary  prerequi- 
sites are  met  for  using  certain  code  structures 
before  they  are  actually  invoked;  thus,  required 
initializations  and  declarations  are  often  omitted 
when  code  is  first  generated.  A symbolic  execution 
of  an  entire  section  of  code  often  permits  these 
omissions  to  be  detected. 
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"The  symbolic  execution  cycle  is  not,  of  course, 
always  successful  at  generating  code  giving  a 
correct  effect.  When  erroneous  code  is  generated, 
there  is  no  back-up  to  a correct  state,  as  would 
take  place  in  a tree-search  problem  solving  process. 
Instead,  the  information  in  the  effect  of  the  wrong 
code  and  in  the  plan  are  used  to  attempt  to  correct 
the  difficulty,  often  by  adding  additional  code  to 
fulfill  unmet  pre-conditions  or  by  minor  modi- 
fications in  the  code  that  has  been  written.  In 
most  cases,  these  corrections  are  successful;  when 
they  do  fail  to  achieve  correct  code,  the  planning 
process  may  again  be  invoked  to  create  a new  plan 
or  piece  of  plan  which  can  be  coded  successfully . 

In  turn,  this  may,  in  a few  rare  occasions,  even 
result  in  a return  to  the  understanding  process. 

This  means  that  as  far  as  the  progression  from 
general  plan  to  specific  solution  goes,  programming 
has  both  top-down  and  bottom-up  phases." 


Fosdick,  Lloyd  D.  "The  Production  of  Better  Mathema- 
tical Software."  Communications  of  the  ACM,  July  1972. 

"There  are  simple,  obvious  things  for  programs 
written  in  the  standard  languages  which  would 
improve  their  portability.  One  is  to  put  all 
machine-dependent  parameters  in  one  place,  identify 
them  as  such,  and  give  a prescription  for  changing 
them  if  the  machine  environment  changes . Programs 
frequently  have  parameters  which  control  storage 
allocation,  execution  time,  and  accuracy.  Again 
these  should  be  brought  together,  identified,  and 
prescriptions  given  for  changing  them,  which  might 
help  a user  willing  to  sacrifice  one  for  the  other, 
say  speed  for  accuracy." 


Kennedy,  T.C.S.  and  Facey,  P.V.  Mini-Comyuter-Based 
Hospital  Administration  System.  (Quoted  in  International 
Journal  of  Man-Machine  Stories,  April  1973)  . 

"The  first  criterion  for  successful  interactive  use 
of  a system  is  that  it  should  be  unnecessary  for 
the  user  to  refer  to  coding  books  or  lists  for 
command  sequences  or  data  entry.  The  user  may  be 
prompted  in  the  case  of  incorrect  entry.  Commands 
should  be  simple  in  format  and  command  verbs  should 
be  self  explanatory.  The  most  satisfactory  data 
entry  procedure  has  been  shown  to  be  a question  and 
answer  sequence  since  a positive  request  for  data 
is  given  which  reduces  the  possibility  of  omission. 
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Each  entry  may  be  validated  as  it  is  made  allowing 
immediate  correction  in  the  case  of  error.  It  is 
possible,  with  this  type  of  system,  for  a totally 
naive  user  to  perform  satisfactorily  with  the 
simple  instruction  that  he  must  terminate  any  entry 
with  the  carriage  return  key  before  the  computer 
'understands'  it. 

"Secondly,  the  computer  or  terminal  should  not  seem 
to  take  command.  The  user  must  maintain  or  appear 
to  maintain  complete  control  of  the  system." 

"If  these  criteria  are  met,  the  man-machine  inter- 
action remains,  on  the  surface,  a simple,  flexible 
procedure  which  allows  a fast  and  efficient  use  of 
the  computer.  However,  it  calls  for  complex 
programs  and  a language  which  possesses  powerful 
string  handling  facilities." 


Liskov,  B.H.  "A  Design  Methodology  for  Reliable  Software 
Systems."  AFIPS,  1972. 

"Levels  of  abstraction  were  first  defined  by 
Dijkstra.  They  provide  a conceptual  framework  for 
achieving  a clear  and  logical  design  for  a system. 
The  entire  system  is  conceived  as  a hierarchy  of 
levels,  the  lowest  levels  being  those  closest  to 
the  machine.  Each  level  supports  an  important 
abstraction;  for  example,  one  level  might  support 
segments  (named  virtual  memories) , while  another 
(higher)  level  could  support  files  which  consist  of 
several  segments  connected  together." 

"Levels  of  abstraction,  which  will  constitute  the 
partitions  of  the  system,  are  accompanied  by  rules 
governing  some  of  the  connections  between  them. 

There  are  two  important  rules  governing  levels  of 
abstraction.  The  first  concerns  resources  (I/O 
devices,  data) : each  level  has  resources  which  it 

owns  exclusively  and  which  other  levels  are  not 
permitted  to  access.  The  second  involves  the 
hierarchy:  lower  levels  are  not  aware  of  the  ex- 

istence of  higher  levels  and  therefore  may  not 
refer  to  them  in  any  way.  Higher  levels  may  appeal 
to  the  (external)  functions  of  lower  levels  to 
perform  tasks;  they  may  also  appeal  to  them  to 
obtain  information  contained  in  the  resources  of 
the  lower  levels." 

» 

"Structured  programming  is  obviously  applicable  to 
system  implementation.  We  do  not  believe  that  by 
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itself  it  constitutes  a sufficient  basis  for  system 
design;  rather  we  believe  that  system  design  should 
be  based  on  identification  of  levels  of  abstraction. 
Levels  of  abstraction  provide  the  framework  around 
which  and  within  which  structured  programming  can 
take  place.  Structured  programming  is  compatible 
with  levels  of  abstraction  because  it  provides  a 
comfortable  environment  in  which  to  deal  with 
abstractions.  Each  structured  program  component 
is  written  in  terms  of  the  names  of  lower-level 
components;  these  names,  in  effect,  constitute  a 
vocabulary  of  abstractions." 

"It  is  not  clear  exactly  how  early  structured  pro- 
gramming of  the  system  should  begin.  Obviously, 
whenever  the  urge  is  felt  to  draw  a flowchart,  a 
structured  program  should  be  written  instead." 


McGregor,  Bob.  "Program  Maintenance."  Data  Processing, 
May- June  1973. 

"New  Systems  development,  in  my  opinion,  cannot 
serve  as  a justification  for  lack  of  maintenance. 
Effective  maintenance  creates  user  goodwill.  It 
gains  user  acceptance  and  assistance.  It  assists 
the  user  to  perform  more  effectively." 

"On  one  hand  his  staff  is  interested  in  developing 
projects  while  goodwill  is  to  be  gained  through 
satisfying  the  immediate  needs  of  the  user.  The 
data  processing  manager  is  constantly  faced  with 
the  problem  of  rotating  staff  from  development  work 
to  maintenance  work,  dressing  up  maintenance  work 
to  look  like  it  is  something  else  and,  in  general, 
paying  a very  high  cost  for  maintenance  control." 

"I  propose  a different  solution  to  this  problem — 
the  use  of  consultant  programmers." 

"The  first  thing  to  consider  is  how  such  a concept 
could  be  put  into  practical  operation.  First,  a 
position  such  as  maintenance  manager  must  be  created. 
It  must  be  filled  by  an  in-house  employee  who  re- 
ports directly  to  the  dp  manager." 

"The  appointment  of  the  maintenance  manager  gives 
the  organisation  a vehicle  for  developing  individual 
skills  at  a prestigious  level.  Maintenance  pro- 
gramming or  'fireman'  work  is  an  art  unto  itself, 
and  requires  special  skills  and  talents.  Rotating 
more  senior  staff  members  through  this  position 
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will  enable  them  to  acquire  these  skills  without 
feeling  they  are  working  beneath  their  capability." 


Madnick,  Stuart  E.  and  Alsop,  Joseph  W. , II.  "A  Modular 
Approach  to  File  System  Design."  AFIPS,  1969. 

"The  notions  of  'levels  of  abstraction'  or 
'hierarchical  modularity'  can  best  be  presented 
briefly  by  an  example.  Consider  an  aeronautical 
engineer  using  a matrix  inversion  package  to  solve 
space  flight  problems.  At  his  level  of  abstraction, 
the  computer  is  viewed  as  a matrix  inverter  that 
accepts  the  matrix  and  control  information  as  input 
and  provides  the  inverted  matrix  as  output.  The 
application  programmer  who  wrote  the  matrix  inver- 
sion package  need  not  have  had  any  knowledge  of  its 
intended  usage  (superior  levels  of  abstraction) . 

He  might  view  the  computer  as  a 'FORTRAN  machine,' 
for  example,  at  his  level  of  abstraction.  He  need 
not  have  any  specific  knowledge  of  the  internal 
operation  of  the  FORTRAN  compiler  implementer 
operates  at  a different  (lower)  level  of  abstraction. 
In  the  above  example  the  interaction  between  the  3 
levels  of  abstraction  is  static  since  after  the 
matrix  inversion  program  is  completed,  the  engineer 
need  not  interact,  even  indirectly,  with  the 
applications  programmer  or  compiler  implementer. 

In  the  form  of  hierarchical  modularity  used  in  the 
file  system  design  model,  the  multi-level  inter- 
action is  continual  and  basic  to  the  file  system 
operation. " 


Parnas,  D.L.  "On  the  Criteria  to  Be  Used  in  Decomposing 
Systems  into  Modules . " Communications  of  the  ACM, 
December  1972. 

"Usually  nothing  is  said  about  the  criteria  to  be 
used  in  dividing  the  system  into  modules.  This 
paper  will  discuss  that  issue  ..." 

"Below  are  several  partial  system  descriptions 
called  modularizations . In  this  context  'module' 
is  considered  to  be  a responsibility  assignment 
rather  than  a sub-program. " 

"This  is  a modularization  in  the  sense  meant  by 
all  proponents  of  modular  programming.  The  system 
is  divided  into  a number  of  modules  with  well- 
defined  interfaces;  each  one  is  small  enough  and 
simple  enough  to  be  thoroughly  understood  and  well 
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programmed.  Experiments  on  a small  scale  indicate 
that  this  is  approximately  the  decomposition  which 
would  be  proposed  by  most  programmers  for  the  task 
specified. " 

"In  the  first  decomposition  the  criterion  used  was 
to  make  each  major  step  in  the  processing  a module. 
One  might  say  that  to  get  the  first  decomposition 
one  makes  a flowchart.  This  is  the  most  common 
approach  to  decomposition  or  modularization.  It 
is  an  outgrowth  of  all  programmer  training  which 
teaches  us  that  we  should  begin  with  a rough  flow- 
chart and  move  from  there  to  a detailed  implementa- 
tion. " 

"The  second  decomposition  was  made  using  1 infor- 
mation hiding'  as  a criterion.  The  modules  no 
longer  correspond  to  steps  in  the  processing." 

"In  addition  to  the  general  criteria  that  each 
module  hides  some  design  decision  from  the  rest  of 
the  system,  we  can  mention  some  specific  examples 
of  decompositions  which  seem  advisable. 

1.  A data  structure,  its  internal  linkings, 
accessing  procedures  and  modifying  procedures  are 
part  of  a single  module.  They  are  not  shared  by 
many  modules  as  is  conventionally  done." 

"2 . The  sequence  of  instructions  necessary  to  call 
a given  routine  and  the  routine  itself  are  part  of 
the  same  module.  This  rule  was  not  relevant  in  the 
Fortran  systems  used  for  experimentation  but  it 
becomes  essential  for  systems  constructed  in  an 
assembly  language . " 

"3.  The  formats  of  control  blocks  used  in  queues 
in  operating  systems  and  similar  programs  must  be 
hidden  within  a 'control  block  module.'  It  is 
conventional  to  make  such  formats  the  interfaces 
between  various  modules.  Because  design  evolution 
forces  frequent  changes  on  control  block  formats 
such  a decision  often  proves  extremely  costly." 

"4 . Character  codes,  alphabetic  orderings,  and 
similar  data  should  be  hidden  in  a module  for 
greatest  flexibility. 

"5.  The  sequence  in  which  certain  items  will  be 
processed  should  (as  far  as  practical)  be  hidden 
within  a single  module.  Various  changes  ranging 
from  equipment  additions  to  unavailability  of 
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certain  resources  in  an  operating  system  make 
sequencing  extremely  variable." 

"In  discussions  of  system  structure  it  is  easy  to 
confuse  the  benefits  of  a good  decomposition  with 
those  of  a hierarchical  structure.  We  have  a 
hierarchical  structure  if  a certain  relation  may 
be  defined  between  the  modules  or  programs  and 
that  relation  is  a partial  ordering." 

" . . .we  must  conclude  that  hierarchical 
structure  and  'clean'  decomposition  are  two  desir- 
able but  independent  properties  of  a system  structure." 

"We  have  tried  to  demonstrate  by  these  examples  that 
it  is  almost  always  incorrect  to  begin  the  decompo- 
sition of  a system  into  modules  on  the  basis  of  a 
flowchart.  We  propose  instead  that  one  begins  with 
a list  of  difficult  design  decisions  or  design 
decisions  which  are  likely  to  change.  Each  module 
is  then  designed  to  hide  such  a decision  from  the 
others.  Since,  in  most  cases,  design  decisions 
transcend  time  of  execution,  modules  will  not 
correspond  to  steps  in  the  processing." 


Prokop,  J.S.  and  Brooks,  F.P.,  Jr.  "Decision  Making 
with  Computer  Graphics  in  an  Inventory  Control  Environ- 
ment." AFIPS,  March  1971.  (Quoted  in  Computing  Reviews, 
April  1971. 

"This  paper  describes  a well-conceived  experiment 
in  which  18  people  participated.  Near  the  end  of 
20  hours  of  instruction  in  advanced  inventory 
control  techniques,  each  participant  was  given 
statistics,  resulting  from  two  different  simulation 
runs — for  example,  percent  availability  of  stock, 
number  of  purchase  orders  generated,  cost  of  sales, 
and  total  dollar  investment  in  inventory.  These 
runs  contained  12  policies  governing  34  items  for 
24  periods.  At  the  end  of  each  period,  each 
participant  ranked  the  policies  in  order  of  de- 
sirability. 

"In  one  run,  all  information  appeared  as  hard-copy 
tabular  listings.  For  the  other  run,  subsets  of 
the  listing  could  be  displayed  via  the  Programmed 
Function  Keyboard  of  an  IBM  2250. 

"The  results  support  the  conclusion  that  better 
decisions  can  be  made  earlier  and  faster  using  dis- 
plays  instead  of  printout." 
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Rhodes,  John.  "Tackle  Software  with  Modular  Program- 
ming." Computer  Decisions,  October  1973. 

"Maintenance  is  one  of  the  most  expensive  activities 
within  any  programming  department:  The  original 

programming  costs  for  a project  often  become  small 
in  relation  to  the  aggregate  maintenance  costs 
after  a few  years  of  operation. 

"When  planning  any  change,  a programmer  must  under- 
stand the  program  to  be  changed;  decide  where  and 
how  to  make  the  change;  and  check  that  the  change 
will  not  produce  unwanted  results.  Having  made 
the  alterations,  he  must  retest  and  update  the 
documentation.  Modular  programming  can  make  these 
tasks  simpler. 

"Since  programs  are  subdivided,  the  programmer  can 
easily  identify  the  module  to  be  amended,  even  if 
he  did  not  write  the  original  program.  If  carefully 
considered  standards  have  been  followed,  alteration 
of  the  internal  operation  of  the  module  will  not 
cause  undesired  results.  Retesting  is  necessary 
only  for  the  module  altered.  And  if  documentation 
is  also  modular,  changes  to  it  are  also  easy." 


Schuff,  Fred  and  Schuff,  Stephen  J.  "Mini-Modules 
Reduce  Programming  Effort."  Journal  of  Systems  Manage- 
ment, July  1973. 

"There  is  a growing  interest  in  modular  programming. 
If  applied  in  a logical  and  organized  manner,  it 
may  be  quite  a boon  to  the  development  of  pro- 
gramming code." 

"This  concept  has  proven  very  beneficial  to  the 
planning  and  development  of  large  systems,  but  its 
initial  success  has  kept  the  principle  from  being 
carried  the  next  step  further.  If  a large  system 
can  be  modularized  to  enhance  development,  why  can't 
these  modules  be  'mini-modularized'  to  enhance 
their  programmability?" 

"Mini-modularization  can  be  extended  into  several 
areas  of  programming  tasks : standard  calculation 

techniques,  standard  input/output  (I/O)  modules, 
and  special  utility  functions." 

"The  special  utility  function  mini-modules  are  most 
valuable  to  the  high  level  languages  where  there  is 
usually  no  facility  to  perform  the  function  no 
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matter  how  clever  the  programmer  may  be.  Most  of 
these  routines  are  coded  in  machine  language  and 
employ  features  that  are  only  available  at  this 
level.  These  functions  may  be  thought  of  a frills, 
but  after  they  become  part  of  the  system,  they 
often  become  tremendous  savers  of  time  and  effort. 
Examples  are  routines  to  intercept  program 
failures  (abends/interrupts)  and  allow  corrective 
action  by  the  application  program;  routines  to 
provide  information  such  as  job  name,  data  set 
names,  CPU  times,  etc. 

"A  final  consideration  must  be  given  to  the  fact 
that  the  long  range  cost  of  maintenance  or  up- 
grading a system  at  a later  date  is  greatly  re- 
duced. Maintenance  is  limited  to  the  code  that 
is  external  to  the  mini-modules,  due  to  their 
proven  reliability  and  the  search  required  to 
detect  a problem  is  reduced  significantly.  The 
same  is  true  for  upgrading  the  system;  there  is 
less  external  code  to  be  concerned  with  or,  in  the 
case  where  a mini-module  is  to  be  revised,  the 
mini-module  is  upgraded  and  then  replaced  in  all 
appropriate  systems  without  affecting  any  other 
code  in  the  system." 

"As  each  new  mini-module  is  developed,  the  base  for 
building  new  systems  grows  larger  and  larger.  This 
allows  more  of  the  time  spent  on  each  project  to 
be  allocated  to  other  phases  of  the  project  or  the 
total  allocation  can  be  reduced.  The  result  can 
only  be  a reduced  overall  cost  for  the  system  in 
total. " 


Scott,  Randall  F.  and  Simmons,  Dick  B.  "Programmer 
Productivity  and  the  Delphi  Technique,"  Datamation,  May 
1974. 


"A  review  of  programming  management  literature 
shows  much  commentary  but  very  little  research  on 
programmer  productivity . " 

"Simulation  offers  hope  as  a method  of  obtaining 
insight  into  programmer  productivity;  only  recently 
has  it  been  used  to  study  computer  programming. 

Of  course,  the  use  of  simulation  implies  a knowl- 
edge of  the  active  project  variables  and  their 
interrelationships . 

"Before  beginning  any  programmer  productivity  re- 
search, it  would  be  helpful  to  have  a conference 
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with  some  practicing  managers  and  project  manage- 
ment experts,  although  this  would  be  both  difficult 
to  arrange  and  expensive.  Even  better  results  can 
be  obtained  using  an  inexpensive  iterative  method 
called  Delphi." 

• 

"The  members  of  a typical  Delphi  panel  never  meet 
each  other.  This  eliminates  the  possibility  of  a 
small  vocal  minority  swaying  the  responses  of  other 
members.  Reputations  are  neutralized  by  the 
anonymous  feature  of  the  survey." 

"The  statistical  group  response  feature  provides 
for  recognition  that  the  exact  answer  is  unknown 
and  the  value  of  all  final  responses  should  be 
maintained.  This  type  of  response  helps  reduce 
group  pressure." 

"Instead  of  future  events,  the  Delphi  statements 
were  defined  as  variables.  The  panel  members  were 
asked  to  correlate  each  variable  with  programmer 
productivity,  which  was  defined  as  implemented 
object  instructions  generated  per  unit  of  time. 

The  panel  members  were  asked  to  correlate,  on  a 
scale  from  minus  seven  to  plus  seven,  the  effect 
on  programmer  productivity  of  increasing  the  magni- 
tude of  each  variable." 

"Table  4 includes  22  variables  on  which  there  was 
a consensus  after  round  two." 


Variable  Median 


"Quality  of  external  documentation  6 

Programming  language  5 

Availability  of  programming  tools  5 

Programmer  experience  in  data  processing  5 

Programmer  experience  in  functional  area  5 

Effect  of  project  communications  5 

Independent  modules  for  task  assignment  4 

Well-defined  programming  practices  4 

Central  hardware  3 

Quality  of  internal  documentation  3 

Personnel  turnover  rate  -3 

Complexity  of  operating-system/ 

programmer  interface  -3 

Customer  adp  experience  3 

Appropriate  documentation  standards  3 


Table  4.  Round  2 consensus 
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Table  4 (Cont'd.) 


Variable  Median 


"Availability  of  documentation  aids  3 
Peripheral  hardware  2 
Use  of  structured  programming  2 
Programmer  participation  in  setting  goals  2 
Complexity  of  application  1 
Number  of  installations  0 
Shop  environment  (open  or  closed  shop)  0 
Number  of  unconditional  transfer 

statements  in  the  source  program  0" 


"These  results  clearly  point  up  the  importance 
that  programming  project  managers  place  on  pro- 
viding the  working  programmer  with  a well- 
documented,  thoroughly  defined,  independent  task. 
Experienced  programmers  working  in  high  level 
languages  were  also  considered  very  important. 
Environmental  factors  such  as  hardware  and 
operating  system  complexity,  and  open  or  closed 
programming  shop  did  not  receive  high  ratings. 

"Another  revealing  result  was  variable  31  (number 
of  unconditional  transfer  statements  in  the  source 
program) . There  was  a consensus  since 
the  range  was  one;  but  the  median  was  zero.  From 
this  result  it  is  obvious  that  this  panel  of  experts 
does  not  feel  the  controversy  on  the  importance  of 
unconditional  transfer  statements  ("GO  TO"  contro- 
versy) is  worthwhile  in  its  effect  on  programmer 
productivity. " 


Sime,  M.E. , Green,  T.R.G.,  and  Guest,  D.J.  "Psycho- 
logical Evaluation  of  Two  Conditional  Constructions  Used 
in  Computer  Languages . " Int.  J.  Man-Machine  Studies, 


1973. 


"There  is  a need  for  empirical  evaluation  of  pro- 
gramming languages  for  unskilled  users,  but  it  is 
more  effective  to  compare  specific  features  common 
to  many  languages  than  to  compare  complete  languages. 
This  can  be  done  by  devising  micro-languages 
stressing  the  feature  of  interest,  together  with  a 
suitable  subject  matter  for  the  programs.  To 
illustrate  the  power  of  this  approach  two  con- 
ditional constructions  are  compared:  a nestable 

construction,  like  that  of  Algol  60,  and  a branch- 
to- label  construction,  as  used  in  many  simpler 


languages.  The  former  is  easier  for  unskilled 
subjects. " 

"The  results  of  the  present  study  indicate  unequivo- 
cally that  the  NEST  micro-language  was  easier  for 
our  subjects  than  JUMP.  Reservations  must  still 
be  made,  however,  when  interpreting  these  results. 
For  the  complete  beginner  no  separation  can  be  made 
between  ease  of  learning  a language  and  ease  of 
using  it,  yet  for  many  practical  purposes  one  might 
wish  to  trade  off  one  for  the  other.  Again,  we 
deliberately  avoided  a source  of  severe  difficulty 
in  many  programming  languages,  the  expression  of 
the  scope  of  the  conditional  expression." 

"Finally,  it  may  be  worth  a small  amount  of 
speculation  on  the  question  of  embedding.  It  was 
clear  that  the  NEST  group  had  greater  difficulty 
with  the  harder  problems.  If,  as  seems  likely, 
this  is  due  to  the  increase  in  depth  of  embedding, 
the  question  is  whether  syntactic  devices  to 
reduce  the  depth  of  embedding  would  make  a sig- 
nificant contribution.  Such  devices  include  well- 
tried  methods,  like  the  Boolean  operators  and,  or, 
etc . , which  in  the  problems  used  would  reduce  the 
degree  of  embedding  to  zero  and  presumably  make  the 
task  much  easier." 


Simmons,  Dick  B.  "The  Art  of  Writing  Large  Programs." 
IEEE  Trans ♦ Computers , March/April  1972. 

"When  writing  small  programs,  one  can  use  many  un- 
wise practices  which  have  little  effect  on  whether 
a program  meets  its  design  objectives  as  long  as 
the  program  works.  But,  when  writing  large  pro- 
grams, poor  program  writing  techniques  can  increase 
development  time  and  cost  and  can  cause  mainte- 
nance difficulties  after  development." 

"Many  independent  workers  have  come  up  with  what 
could  be  considered  facts  that  we  must  live  with 
while  developing  large  programming  systems  1,  2,  3, 
7.  Some  of  these  facts  are: 

"Programmer  Turnover  - Anyone  who  has  been  involved 
in  writing  large  programs  has  observed  personnel 
turnover  problems.  Corbato  has  said  that  when 
planning  a long  term  programming  project,  one  should 
assume  there  will  be  roughly  a 20%  per  year 
personnel  turnover.  Though  industry  does  not  like 
to  advertise  personnel  turnover  problems,  a figure 
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of  20%  is  also  representative  for  many  of  the 
large  programming  projects  developed  in  industry." 

"Hardware/Software  Turnover  - . . . During  program 
development  when  larger  and  faster  disks,  new  types 
of  remote  terminals  or  even  faster  and  larger 
processors  become  available,  these  are  usually  in- 
tegrated into  the  system.  Though  computation 
centers  try  to  minimize  the  effect  on  users  during 
upgrading  of  systems,  often  the  user  is  without  a 
system  for  a considerable  amount  of  time.  The 
same  is  true  whenever  a new  software  system  is 
introduced  into  a computation  center.  Often  a 
major  software  system  cut-over  causes  system 
outages . " 

"Major  Ideas  Incorporated  Late  - Major  ideas  to  be 
incorporated  in  a program  often  originate  after 
the  program  is  written  and  nearly  debugged." 

"Program  Never  Debugged  - No  major  program  will 
ever  be  completely  debugged.  Throughout  the  life 
of  any  major  program,  bugs  develop  and  have  to  be 
corrected." 

"Program  Maintenance  - Every  major  program  must  be 
revised,  updated  or  otherwise  maintained.  The 
program  must  be  maintained  by  people  other  than  the 
ones  who  originally  wrote  the  program." 

"Though  there  may  be  other  important  factors  not 
included  in  the  above,  the  list  does  contain 
salient  facts  that  must  be  contended  with  during 
development  of  any  large  programming  system." 

"Any  large  program  should  be  partitioned  into 
modular  blocks.  Each  block  should  be  as  self- 
contained  as  possible.  The  number  of  programmers 
working  on  the  same  module  should  be  kept  as  small 
as  possible.  In  many  instances  it  has  been 
observed  that  no  more  than  ten  people  can  be 
employed  usefully  in  developing  a single  program 
module.  A better  limit  would  be  six  which  is  the 
largest  number  of  people  that  should  be  under  a 
single  supervisor.  A program  should  be  partitioned 
so  that  interconnections  between  blocks  are 
minimized. " 

"One  way  of  monitoring  is  the  buddy  system  where 
each  program  must  be  completely  understood  by  the 
original  programmer  and  at  least  one  other  pro- 
grammer. During  the  writing  and  debugging  phases 
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each  programmer  continually  interfaces  with  a 
buddy  who  is  able  to  understand  his  program.  The 
buddy  system  falls  down  when  two  inexperienced 
programmers  are  paired  together." 

"A  design  review  committee  made  up  of  experienced 
programmers  is  another  technique  for  monitoring 
program  development." 

"Both  the  buddy  system  and  the  design  review 
committee  divert  manpower  from  the  main  task  of 
developing  programs.  Though  in  the  long  run  the 
manpower  is  well  invested,  it  would  be  desirable 
to  develop  an  automatic  technique  for  monitoring 
program  development.  Automatic  monitoring  of 
program  documentation  is  possible.  For  example, 
when  flowcharts  are  produced  directly  from  program 
listings,  a high  quality  flowchart  of  proper 
detail  can  be  produced  only  from  a listing  that 
has  been  properly  commented." 

"Proper  grouping  of  program  statements  can  greatly 
add  to  the  readability  of  a program.  For  example, 
a program  should  not  be  designed  so  the  control 
oscillates  around  a large  area  of  statements  thus 
requiring  programmers  to  flip  pages  back  and  forth 
while  trying  to  read  the  program  listing.  Branches 
of  a conditional  transfer  should  be  placed  close 
together  if  they  eventually  come  back  together  in 
the  main  line  of  code.  Programs  should  be  properly 
broken  into  standard  sections  to  make  them  easier 
to  understand." 

"The  following  documentation  should  exist  in  some 
form  for  programs: 

"Program  Description  - As  a first  step  in  program 
documentation,  the  programmer's  comments  can  serve 
as  a program  description.  This  description  can  be 
updated  and  modified." 

"Program  Listing  - A program  listing  as  we  think 
of  it  today  is  the  main  item  used  by  a programmer 
to  create  a program  and  to  understand  someone 
else's  program.  Comments  are  necessary  whether  a 
program  is  written  in  assembler  language  or  in  a 
high  level  language.  A program  should  not  be  over- 
commented, but  comments  should  be  placed  throughout 
programs  to  explain  anything  that  might  be  unclear 
to  someone  reading  the  program." 
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"Comments  placed  within  a program  should  state  the 
purpose  of  a program  sequence  rather  than  describe 
the  operation  of  program  statements. 

"Program  comments  can  be  classified  as  heading 
comments  and  explanatory  comments.  Heading 
comments  should  appear  at  the  beginning  of  any 
major  program  section  such  as  a program  subroutine. 
They  should  explain  the  function  of  the  program 
section,  define  inputs  to  and  outputs  from  the 
section,  etc.  Explanatory  comments  are  normally 
attached  to  program  statements  or  immediately  before 
them.  These  comments  should  explain  what  each 
section  of  a program  does  and  should  only  explain 
what  an  instruction  is  doing  when  the  function 
of  the  instruction  is  ambiguous." 

"Data  Layout  - The  data  layout  section  of  a program 
normally  consists  of  data  definition  statements 
written  in  a one-dimensional  syntax.  Data  is 
defined  normally  in  a linear  language  from  which 
someone  can  draw  a two-dimensional  description  of 
the  data.  Two-dimensional  layouts  should  be  pro- 
duced automatically  just  as  two-dimensional 
flowcharts. h 


Sutherland,  William  R. , Porgie,  James  W. , and  Morello, 
Marie  V.  "Graphics  in  Time-Sharing:  a Summary  of  the 

TX-2  Experience."  AFIPS,  October  1969.  (Quoted  in 
Computing  Reviews,  November  1969. 

"Ten  years  of  experience  in  interactive  computer 
graphics,  with  five  of  those  years  in  a time- 
sharing environment,  provides  a unique  source  of 
material  for  this  thorough  and  interesting  look  at 
lincoln  Lab's  TX-2  computer." 


Walker,  A.W.  "An  Interactive  Graphical  Debugging  System." 

Computer  Abstracts,  February  1972. 

"A  system  is  described  which  provides  an  inter- 
active graphical  debugging  facility  for  user  pro- 
grams. This  system  is  implemented  on  an  Adage 
AGT-10  and  is  operational  for  online  debugging  of 
higher-level  language  programs  executing  on  an  XDS 
9300  host  computer.  System  architecture  and 
implementation  are  discussed.  A formal  definition 
of  the  DEBUG  Command  Language  is  given  and  a 
description  of  the  utilization  of  the  commands  for 
program  debugging  is  presented." 
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Weinwurm,  George  F.  (Ed.)  On  the  Management  of  Computer 
Programming.  Auerbach,  Princeton,  N.J.,  1970.  (Quoted 
in  Computing  Reviews , May  1971.) 

"It  comes  as  a distinct  shock  to  the  uninitiated 
that,  for  an  activity  that  accounts  for  the  ex- 
penditure of  several  billion  dollars  a year  in  the 
United  States  alone,  the  management  of  computer 
programming  is  still  something  of  a black  art." 


Wirth,  Niklaus.  "Program  Development  by  Stepwise  Re- 
finement." Communications  of  the  ACM,  April  1971. 

"...  the  student  obtains  the  impression  that 
programming  consists  mainly  of  mastering  a language 
(with  all  the  peculiarities  and  intricacies  so 
abundant  in  modern  PL's  and  relying  on  one's 
intuition  to  somehow  transform  ideas  into  finished 
programs.  Clearly,  programming  courses  should 
teach  methods  of  design  and  construction,  and  the 
selected  examples  should  be  such  that  a gradual 
development  can  be  nicely  demonstrated. " 

"This  paper  deals  with  a single  example  chosen  with 
those  two  purposes  in  mind." 

"In  each  step,  one  or  several  instructions  of  the 
given  program  are  decomposed  into  more  detailed 
instructions.  This  successive  decomposition  or  re- 
finement of  specifications  terminates  when  all 
instructions  are  expressed  in  terms  of  an  under- 
lying computer  or  programming  language  ..." 

"As  tasks  are  refined,  so  the  data  may  have  to  be 
refined,  decomposed,  or  structured,  and  it  is 
natural  to  refine  program  and  data  specifications 
in  parallelTn 

"A  guideline  in  the  process  of  stepwise  refinement 
should  be  the  principle  to  decompose  decisions  as 
much  as  possible,  to  untangle  aspects  which  are 
only  seemingly  interdependent,  and  to  defer  those 
decisions  which  concern  details  of  representation 
as  long  as  possible.  This  will  result  in  programs 
which  are  easier  to  adapt  to  different  environments 
(languages  and  computers) , where  different  repre- 
sentations may  be  required." 

"In  the  practical  world  of  computing,  it  is  rather 
uncommon  that  a program,  once  it  performs  correctly 
and  satisfactorily,  remains  unchanged  forever. 
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Usually  its  users  discover  sooner  or  later  that 
their  program  does  not  deliver  all  the  desired 
results,  or  worse,  that  the  results  requested  were 
not  the  ones  really  needed.  Then  either  an  extension 
or  a change  of  the  program  is  called  for,  and  it 
is  in  this  case  where  the  method  of  stepwise 
program  design  and  systematic  structuring  is  most 
valuable  and  advantageous.  If  the  structure  and 
the  program  components  were  well  chosen,  then  often 
many  of  the  constituent  instructions  can  be  adopted 
unchanged.  Thereby  the  effort  of  redesign  and 
reverification  may  be  drastically  reduced.  As  a 
matter  of  face,  the  adaptability  of  a program  to 
changes  in  its  objectives  (often  called  maintain- 
ability) and  to  changes  in  its  environment  (now- 
adays called  portability)  can  be  measured  primarily 
in  terms  of  the  degree  to  which  it  is  neatly 
structured. " 

"The  detailed  elaborations  on  the  development  of 
even  a short  program  form  a long  story,  indicating 
that  careful  programming  is  not  a trivial  subject. 

If  this  paper  has  helped  to  dispel  the  widespread 
belief  that  programming  is  easy  as  long  as  the 
programming  language  is  powerful  enough  and  the 
available  computer  is  fast  enough,  then  it  has 
achieved  one  of  its  purposes." 
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CONCEPTUAL  GROUPING  PROGRAM  FOR  FORTRAN  (GP-F) 


1.  GENERAL  SYSTEM  DESCRIPTION 

As  a very  general  rule,  it  is  helpful  to  know  what  a 
person  looks  at,  or  perceives,  when  he  works.  Previous 
research  has  shown  that  a maintenance  programmer  tends 
to  work  with  "conceptual  groupings"  in  a programming 
language.  Thus,  the  following  suggestion  has  been  made: 
The  programmer  could  be  helped  in  his  work  if  he  could 
be  helped  to  recognize  these  "groupings."  The  Groupings 
Program  for  FORTRAN  (GP-F)  is  intended  to  provide  a way 
of  experimentally  pointing  out  the  groupings  to  mainte- 
nance programmer.  Thus  it  permits  experimentation  re- 
garding the  efficiencies  of  maintenance  programming  that 
might  be  gained  if  such  a system  were  implemented 
operationally . 

Functions  of  the  GP-F  may  be  specified  as  follows: 

Given  a FORTRAN  program  as  input,  the  GP-F  should  output 
a listing  of  that  program,  using  various  techniques 
(described  later  in  Paragraph  2.2)  to  identify  con- 
ceptual groupings  of  statements. 

For  experimentation,  the  GP-F  should  selectively  apply 
(according  to  the  researcher's  specifications)  various 
subsets  of  those  techniques,  to  produce  different 
patterns  of  groupings. 

The  GP-F  should  accept  input  either  on  cards,  disc,  or 
tape;  and  it  should  provide  output  on  these  or  a line 
printer.  It  should  also  accept  standard  FORTRAN  IV  decks 
of  any  length  and  complexity,  and  provide  output  that 
is  also  standard  FORTRAN.  If  compiled,  the  output 
should  give  results  compatible  with  the  compilation  of 
the  input  deck. 


2.  FUNCTIONAL  SPECIFICATIONS  (GP-F) 


2.1  Input/Output  Specifications 

The  GP-F  should  allow  input  from  a variety  of  sources  and 
be  able  to  provide  output  in  the  form  of  cards  and 
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listings.  The  program  should  allow  for  the  user  to 
determine  the  Input/Output  specifications  and  the 
specifications  which  control  the  editing  processes  of 
the  GP-F.  The  GP-F  should  allow  multiple  routines 
(i.e.,  Programs,  Subroutines,  and  Functions)  within  the 
same  input  file.  The  program  should  process  each 
routine  within  the  input  file  independently  of  the 
other  routines , resetting  itself  when  initialized  and 
after  each  routine.  The  GP-F  might  be  designed  to 
accept  input  files  where  END  statements  indicate  the 
end  of  routines. 


2 . 2 Program  Functions 


The  GP-F  should  implement  the  following  functions  for 
identification  of  conceptual  groups: 

(1)  It  should  identify  and  point  out  groupings 
characterized  by  like  statement  types. 

(2)  It  should  perform  the  following  additional 
functions: 

Print  formats  under  each  referencing  I/O 
statement; 

Sort  declaratives  to  beginning  of  the 
program; 

Indent  nested  do  loops; 

Mark  transfer  statements  for  easy 
identification; 

Mark  I/O  statements. 


2.3  Check  for  Like-Statement  Groups 


2.3.1  Description 

This  function  should  cause  the  program  to  look  for 
statement  groups  that  contain  a certain  percentage  of 
like  statements.  A like-statement  group  would  be  a 
group  of  statements  which  contains  a certain  percentage 
of  statements  of  one  type.  Given  that  a maximum  size 
and  minimum  size  of  the  like- statement  group  is  known, 
the  GP-F  should  determine  whether  a group  of  statements 
is  a like-statement  group  by  determining  if  any  one 
statement  type  occurs  within  that  group  more  than  a 
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specified  percentage  of  the  time.  If  a group  had  twenty 
statements,  of  which  fifteen  were  "assignment"  state- 
ments, and  the  criteria  was  60%  this  group  would  be 
classified  as  a "Like-Statement  group."  Like- 
statement  groups  should  include:  I/O  Transfer,  and 

Assignment. 


2.3.3  Implementation 

The  program  should  be  preset  with  values  for  the  maximum 
and  minimum  group  size  and  the  percentage  of  statements 
of  one  type  that  determines  a Like-Statement  group.  The 
program  could  then  scan  the  input  in  blocks  of  state- 
ments with  the  maximum  size  and  determine  the  type  of 
each  statement.  This  would  enable  the  calculation  of 
type  percentages  which  in  turn  would  determine  the 
existence  of  a "Like-Statement  group." 


2 . 4 Print  Formats  Under  Each  I/O  Statement 


2.4.1  Description 

This  function  should  cause  format  statements  to  be 
printed  after  EVERY  input/output  statement  which 
references  that  format  statement.  Formats  should  not 
appear  in  the  location  they  were  in  the  original  input 
deck  unless  that  location  followed  a referencing  I/O 
statement.  All  occurrences  of  the  format  statement 
except  the  first  occurrence  would  appear  as  comments  in 
the  output  listing  (i.e.,  with  a "C"  in  column  1). 


2.4.2  Implementation 

The  formats  in  the  program  would  be  grouped  into  a table; 
whenever  an  I/O  statement  was  processed  the  Format 
statement  would  be  appended  to  the  output  file. 


2 . 5 Sort  Declaratives  to  the  Beginning  of  the  Program 


2.5.1  Description 

This  function  should  cause  all  declaratives  to  be  listed 
prior  to  the  beginning  of  the  edited  listing,  offset 
from  the  listing  by  blank  lines.  Declaratives  should 
include:  integer,  real,  common,  dimension,  double  pre- 

cision, complex,  implicit,  and  data  statements. 
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2.5.2  Implementation 

Declaratives  located  during  the  first  pass  of  the 
program,  should  be  sorted  and  printed  at  top  of  listing. 


2 . 6 Indent  Nested  Do  Loops 


2.6.1  Description 

This  function  should  cause  nested  do  loops  to  be  indented 
for  each  nested  loop. 

A simple  DO  loop  begins  with  a DO  statement  and  is  ter- 
minated by  a statement  with  the  label  (statement  number) 
specified  by  the  original  DO  statement.  A nested  DO 
loop  contains  more  than  one  individual  DO  loop.  This 
function  should  cause  indentation  to  occur  for  EACH  level 
in  a NESTED  DO  loop. 


2.6.2  Implementation 

Start  and  end  points  of  DO  loops  should  be  scanned  by 
the  program  which  would  appropriately  set  an  indent- 
controlling variable . 


2.7  Mark  Transfers 


2.7.1  Description 

This  function  should  cause  all  conditional  and  uncon- 
ditional transfer  statements  (If's,  Goto's,  Calls,  etc.) 
to  be  marked.  One  method  of  marking  would  be  to  print 
a dotted  line  beneath  the  statement  containing  the 
transfer.  Other  methods  might  include:  inserting  blank 

lines  before  and/or  after  the  transfer  statement;  over- 
printing the  transfer  statement;  or  printing  a marker 
in  the  margin  before  the  transfer  statement. 


2.7.2  Implementation 

The  program  should  search  for  transfer  statements  by 
examining  input  lines  for  keywords  such  as  "IF,"  "GO  TO," 
or  "CALL"  and  "flag"  these  lines  as  containing  transfer 
statements.  This  flagging  could  be  done  by  using  a 
table  holding  data  on  the  lines  in  the  input.  The  out- 
put routine  for  the  FPP  would  then  examine  this  table  to 
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determine  the  proper  form  and  editing  for  the  line  con- 
taining the  transfer  statement  when  it  is  output. 


2.8  Mark  I/O  Statements 


2.8.1  Description 

This  function  should  cause  all  I/O  operations  to  be 
marked.  One  method  of  marking  would  be  to  offset  the 
I/O  statement  with  blank  lines  before  and  after  the 
statement.  Other  methods  might  include  overprinting, 
indentation,  or  markers  in  the  margin  of  the  output. 


2.8.2  Implementation 
Similar  to  Transfers. 


3 . PROGRAM  IMPLEMENTATION 


3 . 1 Program  Description 

The  prototype  of  the  GP-F  was  designed,  coded,  tested, 
and  implemented  during  the  last  four  months  of  1973. 
The  language  selected  for  this  prototype  was  SITBOL,  a 
modified  version  of  SNOBOL,  a language  designed  for 
string  and  character  processing  and  manipulation.  The 
SITBOL  GP-F  was  run  on  the  DECsystem-10  at  the  Uni- 
versity of  California  at  Irvine. 


3.2  Operational  Features 

The  SITBOL  GP-F  was  designed  to  be  easy  to  revise,  and 
control.  The  program  can  be  run  in  batch  or  timesharing 
mode  on  the  DECsystem-10.  Control  of  the  program's 
operation,  including  the  determination  of  input  and  out- 
put files,  the  control  of  the  program's  editing  functions, 
and  the  control  of  various  debugging  features  is  avail- 
able to  the  user  via  three  methods: 

(1)  Default  parameters; 

(2)  Parameters  accepted  from  terminal; 

(3)  Parameters  set  from  control  disc  file. 
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The  input  file  for  the  program  is  specified  by  the  user 
interactively.  The  output  file  is  specified  when  the 
SITBOL  system  is  initiated  by  the  user.  In  the 
SITBOL/DEC  system-10  environment,  all  I/O  operations 
occur  between  the  program  and  disc.  Use  of  cards,  line 
printers,  tape,  etc.  is  enabled  by  use  of  a file 
transfer  program. 

The  prototype  GP-F  allows  the  user  to  interactively 
specify  certain  control  parameters  that  control  the 
"mark  Like-Statement  groups"  function.  The  user  may 
specify,  within  certain  limitations,  the  values  of: 

MAXSIZE  - maximum  group  size 

MINSIZE  - minimum  group  size 


and 


PERCENT  - the  like-group  determining  percentage. 


3.3  Prototype  Differences  from  Specifications 


3.3.1  Additional  Features 

In  the  prototype  version  of  the  GP-F,  five  additional 
functions  or  processes  were  added.  These  processes, 
controlled  by  the  user  in  a manner  similar  to  the  other 
functions,  enable  various  debugging  routines  and  output 
control  routines.  These  processes  are: 

(1)  No  Indent  Statement  Numbers.  This  switch 
causes  the  indenting  of  nested  do  loop  state- 
ments to  ignore  statement  labels,  which  remain 
near  the  left  margin  rather  than  "following" 
the  statement  when  indented  to  the  right. 

(2)  No  Break  Before  Transfers.  This  switch  in- 
hibits the  program  from  inserting  a blank  line 
before  each  transfer  statement. 

(3)  Listing  Identification.  This  switch  causes  the 
listing  to  contain  information  concerning 
program  version,  setting  of  control  switches, 
and  selection  of  editing  parameters. 

(4)  Debugging  Dump  I/O.  This  switch  causes  the 
program  to  print  on  the  output  file  the  con- 
tents of  the  main  buffer  of  the  program 


138 


whenever  an  I/O  operation  occurs.  This  switch 
was  a debugging  aid  during  program  develop- 
ment and  testing. 

(5)  Debugging  Dump  Like-Statement  Groups.  This 

switch  caused  the  program  to  print  on  the  out- 
put file  certain  variables  which  were  used  in 
the  search  for  Like-Statement  Groups  by  one  of 
the  program's  functions.  This  switch  was  a 
debugging  aid  during  program  development  and 
testing. 


3.3.2  Differences  from  Specifications 

The  prototype  GP-F  differs  from  the  specifications  in 
the  following  ways: 

(1)  The  prototype  GP-F  does  not  sort  declaratives 
by  time  when  the  "Sort  Declaratives  to  the 
Beginning  of  the  Program"  function  is  specified. 
All  declaratives  are  written  at  the  top  of  the 
listing  but  they  are  not  sorted  by  type. 


3.3.3  Markings  for  Output  Listing 

(1)  Transfer  statements  are  marked  by  a "Dotted 
Line"  printed  beneath  the  transfer  statement 
in  the  output  listing. 

(2)  I/O  statements  are  marked  by  a preceding  blank 
line  in  the  output  listing. 

(3)  Like-Statement  groups  are  marked  by  a "Dashed 
Line"  before  and  after  the  statements  forming 
the  group. 

(4)  Output  Form.  The  program  does  not  check  for 
splitting  groupings  across  page  boundaries  in 

the  case  of  lineprinter  output. 


3 . 4 Operational  Deficiencies  and  Bugs 

(1)  The  program  does  not  in  all  cases  prepare  output 
that  is  directly  accepted  by  a FORTRAN  compiler. 
This  is  because  some  editing  functions  that 
insert  blank  lines  or  various  markings  in  the 
output  file  do  not  precede  such  lines  with 
"C's"  to  indicate  comment  statements. 
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APPENDIX  B 


CONCEPTUAL  GROUPINGS  PROGRAM  FOR  FORTRAN  (GP-F) 


4.  CONCEPTUAL  GROUPING  PROGRAM  FOR  FORTRAN 

(GP-F) 

FLOW  CHARTS 
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CONCEPTUAL  GROUPING  PROGRAM  FOR  FORTRAN  (GP-F) 


FLOW  CHARTS 


c 


Start 


) 


Initializa- 

tion 

Ask  for 
Input  File 

Ask  for 
Type  of  Con- 
trol Specs. 

-Default 


Interact 


User  asked  to  supply  name 
of  input  file. 


User  asked  how  program  is 
to  set  control 
specifications . 


Result  of  above  determines 
branch 


Program  assumes  default 
values. 


Program  asks  User  to  specify 
control  specifications. 


Program  reads  control  speci- 
fications from  control  file 
specified  by  User. 


6 
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Program  opens  input  file 
previously  specified  by 
User. 


Program  initializes  variables 
and  tables. 

Next  line  read  from  Input 
file.  Read  lines  from  the 
Input  file,  determine  what 
types  of  statement  and  editing 
required  according  to  control 
specifications.  This  informa- 
tion is  stored  in  the  BUFFER. 

If  END  of  input  file,  STOP. 


If  END  statement,  terminating 
routine,  branch  to  3. 


If  Sort  Declaratives  to  Be- 
ginning of  Program  Switch  is 
on;  if 
statement 
read  is 


Store  It 
in  Table 


■0 


declarative , 
store  it 
in  table. 


If  Print  format  under  every 

I/O  Switch 
is  on;  if 
statement 
is  format 
store  it  in 
table. 


If  Print  I.D.  Switch  is  on, 
OUTPUT  heading  and  Program 
information. 


If  Sort  Declarative  Switch 
is  on,  output  declaratives 
from  table 


Fill 

Buffer 

es 

Call 

Like-St-Grp 

Ck . Routine 

Rewind  input  file. 

CALL  READ  and  EDIT  routines  to  fill 
buffer.  The  BUFFER  contains  all  the  in- 
formation concerning  the  type  of  state- 
ments and  the  editing  functions  that  are 
to  be  performed  during  OUTPUT. 

If  Check  for  Like-Statement  switch  is  on, 
call  routine  to  CHECK  FOR 
LIKE-STATEMENTS  GROUP.  This 
routine  examines  the  state- 
ments in  the  buffer  and 
"whether  a LIKE-STATEMENT  GROUP 
exists.  If  it  does  it  adds  or  changes  the 
buffer  to  include  the  instructions  for 
output  formatting  and  editing. 

CALL  PRINT  ROUTINE.  Outputs  the  infor- 
mation from  the  buffer  performing  the 
proper  editing  as  specified  by  the  in- 
formation and  statements  in  the  buffer. 


If  End,  branch  to  A. 


REFILL  buffer  by  calling 
READ  and  EDIT  routines. 
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APPENDIX  B 


CONCEPTUAL  GROUPINGS  PROGRAM  FOR  FORTRAN  (GP-F) 


5.  PROGRAM  LISTING  OF  GP-F  IN 
SITBOL 
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001i B?  • THr  FOlLOw'*^.  SG'*E  oPU-*D  UrFlNlTJO'-S  T”  ASS  1ST  COnlVfPS ! ON 

(*ai 2”  * r>r  TUI<;  RrHG0*"  t-Roi  SITOOl  to  aw  asSE*'3LY  LrVrL  language 

001*10  * 

001.6'’  • t .'i T H O u ictl",',  — 

Pal  b""  * T-HTS  HROOw'S  „1;>  wujttFN  I'l  'It!  SITbOL  0*1  the  ”EFSvSTEW  US  AT  I'CI 

00200  * A WUHBFR  0‘  Ajnninvs  to  t at  I ^ pr^GRa*  ->U»1VG  DFVELnPMERT 

Pis?*;*  • AN”  TESTIN'*  ARF  SprcIF'C  T ” Th”SF  opFHATIUvS  AM0 

t»02*.o!  * WEFQ  N”1  Br  *..CLUl)F0  I"  ANY  '■DIVERSION,  THERE  IS  A OuFSTjnN  *T 

pa?6”  * this  TIME  jDj  the  faactLY  F0''vr&sjN  will  BE  ”0*'E  and  IF  Tnr 

pa?6'’  * FUTT!.\r.  ”U'’TR,ji  S^TTFhFs  UDFnTIEIED  by  THE  SUFFIX  ,Sw>  NHL  dr 

P 0,10!*  * I hPLFH.FNTE” 

pa32P  * ~ 

0034"  • THr  PARTS  ”F  THE  PROGRAM  WHICH  PR0RA“Lv  MILL  NOT  &F  INCLUDED  JN  ANY 

00360  * ”OvVERP)ON  A T 1 f MR T h ILL  PL  1 UE  FOLLOWING! 

0036”  • 

0040*  » PO'ITTNFS  n ALL Jw  PLI-tFI  10*1  IF  SWITCHES  tq  CDNTnOL  EPJTJNXC  VIA 

00422  • ThPEF  PlSTTNCf  MFTHOHs*.  (GYaTERENTS  23’t-?9’«)  (STATEMENTS  9l9SsS498» 

00440  *S0«t  OTHER  MFfHOH  of  SWITCH  SPECIFICATION  hill  have  TO  BF  ADDER 

P046P  • To  RF.PLACL  these  SECTIONS 

0848*  * 

0050”  • SOME  OF  THE-  SECTIONS  TuaT  AlLOVE”  SELE-TIVF  oUmPInE,  DURING  TESTING 

PUS2”  * HAVE  BEES  S£''0VEU.  ThFSE  SErTIONS  IPEvTtF1EP  WITH  THE  SWITCHES! 

0354”  * P20UMF,SW  *NO  fguJRP.SM  are  HnmEOESSaRV 

00560  * * 

P0S6P  • A el  PECT  1 0*'S  PROVinj*jG  ppogmam  IPENT  TFjcaT  JQN  RAY  PE  pENTTflEO  RY  THE  SWITCH! 
P 0600  * 10. SW 

0362'’'  * ThFSF  are  °R  1 m AR I i.v  Lyr ATED  In  STaT£ME*'TS  702-79S  AND  2V15-2R5*, 

0064*"  ** 

P0A6P  • F*n  Of  DOC  'SF'4TAI  lfi.\  fOH  CONVERSION 

03*60 — * 

V/l  C*07tf  *--- ---- --- 

Pk)72^  • 

“ d7A*  • 

&id7b?  * this  \s  m*>-  to^tkam  po^T°Kocfbso^#  qvlpton  p^oje^t 

0k)76^  • 

0EFB30  »^THr  FOLlORtNS  DELETES  TRAILING  SPACES  FROM  ALL  INPUT  DATA 
00*20  4 1 R I “ * 1 

03840  • SET  t N°JT  VARIABLES  To  BEGIN  PROGRAM 

B0S6P  * * 

03880  * THr  r ULUOw  I NS  nEbir,N*TFS  a PATTERN  OF  DIGITS 

06,00''  VjMtjrHF  = * 01  234P6’o9  ' 

*TSF~rO£LOwfNft  Thru  IAS  DFFINI1E  PaTTFRnS  FDR  YTjfTE RENT  iOENTtFICATfON 
P0O4P  D£F , ° s ' INTFGFR ' ! ' 0 1 MENS  I ON*  • •REAL*  J 'COMMON'  ’ 'DATA' 

P09<>'1  !RN,°  8 'IF*  • *0010'  ’ 'GO  TO'  I 'CALL' 

W9B’’  T,P  * ’READ'  I 'INPUT'  5 'ACCEPT'  ! 'RFRFAD' 

01P0M  n,p  s 'PRINT*  • 'WRITE'  • 'TYPE* 

P1P2P  10. P * I.P  S O.P 

— PIP4B" MT.T  * 4TI0NTINDE'  J 'STOP'  I TEN” • T '^ROGRAMt 

B106P  • MARGIN  IS  the  tNDENT  DISTANCE  FOR  DO  LOOP  INDENTATION 

01080  MARG'N  b ' • 

— 0170" S 

01120  *,,..*#**.**»*•*****••**»*••***•**•♦•*••*•••*••*****••*** 

01140  * LAST  UPDATE  10-2S-73  SUNDAY  11100  AM 

— BJT50 ST  ItU  TXyEY'TS  FFR  TJPLDG.  IVTIN^ACE 

0XJ00  • 

01200  EDITION  « 'EDITION  4,0  11-20.73T 

— *l72ir  T? 

0124?  • PRESET  VARIABLES 

912b*  • 

_Uin  •"  MCE'l’N J T J DrS “Of  SWITCH  CONDITTONS  (DfT/ON> 


8v».nn 


01340 
01320 
-~ri340 
P136*7 
0 1 3 b ?* 
014091 
014*0 
01440 
0146^ 
0146* 

*152*~~ 
*lb4* 
01i>6* 
0156* 
0160* 
01<S20 
“015*0" 
016o^ 
01680 
01700 
0172" 
01740 
0176* 
01760 
01*40 
01*2^ 
01*40 
01860- 
*=-*"018*0”’ 
cn  019*30 
01920 
‘ ~FW* 
01960 
0196* 
020W 
02020 
02040 
— 020*0~ 
0208* 

_ 0214^ 

02140 

02160 

“0ZIF0 

02200 

02220 

~~0Z24*“ 

02260 

02260 


OFF  s * 

ON  s 1 

TOP  jV  1h£  lop  OF  THF  DO  LOU?  STAC* 

TOP  * * 

FNMfroiJ«T  ! S IMF  FORMAT  COUNT  (PASS  ONr) 

FUM/^PhT  r O 

LP'EC  ! S TM£  NUMHER  OF  I^pUT  lIWFS  (PASS  0ME I 

A FJX  WILL  8F  I NSERTFQ  SO  COMT  l NUaT  J On  LINES  WILL  WOT  RE  COUNTED 
LJWE-  = 0 

nLr.nOJWT  ~a»’r«TS  1ME  DrCLA«iTIVES  (PASS  ONF) 
n£C,~pMi,T  = O 

DEFINITION  FOR  \ShCOWQ.FROW  ^FLECTION) 

SWCO^D.FRO"  - * DEF AUL 1 FO  * 

TaPLFS^AWQ  ARRAYS  ********* 


* MUI  DS  REFFRr\rE  JS  FORMAT  * F*RMATS<F#  N0«> 

FORMATS  = TAOLFO 

* woto^  oecl*rmives 

DECL^S  r AK9AY(?*i> 

VTioi'p^T  STAC*  FOR  no  LOOP  wests 

ST  AC*  5 ARKAY(10> 

* »*« 

* Thr  FOLLOWING  TWO  STATFmEnTS  CONTROL  BUFFER  S|7E 

* QurFER  IS  "J9RENTLY  2y 

* RUFF FR  IS  22  X 5 (5  IS  CONSTANT  WI01TH  OF  PUFFER  I 

r 20 

«fr  r aknay< *20, 5* ) rCINSh.RTj) 

* T h*“  FOLLOWING  Thru  2q5  IS  STRJCTLY  POP-10  SpBOL  AWD  is  ONI  Y IWCLUnEP  fqr 

*^_rnt:*UF‘TTSF"^URING  TESTS,  TT  SFTS  SWITCH  CONATIONS  \TJ  A ONF  OF  THREE  HTTHOnS 
PE*DTTY,0  TTY  r ’SWITCH  StLECTION  ( T vPf  IN-  F JLE  • DFFAULT  OR  TTY)* 

°E AUTTY | 1 WLINF  r TTY 

TDFNT(MLINF, *FIlE* ) iSISWQARO, FJLE) 

JOE'1!  (NL  I ME#  • DEFAULT  • ) I S ( D , F ) 

IOENTC^lINL , ’TTY* ) I S ( S^C ARo # T Ty ) 

TTT  r 'LEGAL  RFPLIFS  A®E*  FILE. DEFAULT,  OR  TTY*  I (RE ADTTY f l ) 

* ROUTINE  TO  A Sj\  FOR  INPUT  F ! Lr  wAHE  AND  THEN  SET  SWITCH  DEFAULTS 

!NSKvRTg  TTY  a *ENTER  INPUT  FILE  WARE  * 

WEI NE  * TTY 

I DENT (ml  INI , • f ) SSCFILE.OEF) 

FJLE.N ArtF  a MLiNr  t(SETSw,OEF) 

r ile.wamf  * •FTN.SIT* 

TTY  s 'FIWE  WANE  DEF AULTFQ  * 

SETSWfOEF  TTY  2 


02320 

02320 

02340 


“1523*0 

02380 

024^0 


TMPUTC1 INF* ,FILE*NAHE) 

TTY  r 'INPUT  FILE!  1 FTLE,WAME  * 
FORM.SW  s ON 
“OETCT^W  a ON 
00 » SW  3 ON 
TRN.9H  a ON 
TTTfSW  a ON 
CG.SW  s ON 
INSND.Sh  a ON 
T*2W*?7SW 


opFNEO# f 


"02420" 

02440 

0246F 


SPRFSOTOtSW 
CGOUMP.SW  = 


OFF 
a OFF 
OFF 


IOpSW  a ON 

CG.HAX  x J* 

cg,*t 


l CREADTTY«0) 


'-ft  - ^ 

* • 


( 


Meat*  Fonrj,  Inc. 


02540 

0252* 

02540 

0258'* 
02600 
02620 
02640 
02660 
0268* 
02700 
02720 
02740 
0276O 
0278^ 
0280* 
02*2* 
“F284? 
02560 
02880 
■"02900" 
0292* 
02940 
!T29$0 
02980 
03000 
~F3M2¥“ 
03040 
03060 
03080“ 
^ 03100 
03120 


• »*»*•«»»»»»*»*•*•#•»  #*#•#»#•#•#***#*#*&#*#*#*#*##♦####*###* 

* Tffr'rOLLOwTNr,  ARr  ThE  HEF  I N i t I ONS  of  T^E  VARIOUS  FUNCTIONS 

* UTILI^EO  *N  Tu  l S PROGRAM 


TPRINT^TJ  attempts  TO  PRINT  RUFFFN  (1  thru  B.MARK) 
(USES  PRINT  f 9 j FOR  OUTPUT) 


PRTN^.ST 


REn I T i U 


ATTEMPTS  TO  PRINT  one  STATEMFNT  <L#NO)  USJNG 
T HE  VAPJOU^  SWITCHES  AND  INFORMATION  IN  THE 
PUFFER  TO  PROPERLY  FORMAT  THE  OUTPUT 

READS  ONr  INPUT  LINE  ANjJ  EOITS  JT  PLACING  THF 
I Nf  0RM  AT  I ON  IN  BUFFER  LOCATION  CP,LOC)f  CAN  TAIL, 

EJLLS  RUrFERf  FIRST  MOVS  RFM A J PUFR  OF  RUFFFR  TO  TOP 
OF  BUFFER#  AMp  FINALLY  FILLS  BUFFER  PETuRN I NG 
HJFFFR  SI2E  AS  B.S12F,  OtSI?E  RILL  PE  l¥  EXCEPT 
WHEN  REO I T , L READS  EOF  FRQM  INPUT  FILE 

<this  routine  uses  redit.l  for  input) 


CHfCM.CG 


STMNTfNO 


THIS  ROUTJNE  CHECKS  FQR  THE  FXISTENCF  OF  A 
CONCEPTUAL  GROUP  in  ThF  ogFFFR  OF  MIMjhjM  Sl?E 
IjKlftN  AND  RETURNS  START  POINT  (ST.PT)  ANQ 
END  POINT  CtNO.PT)  OF  CG  IF  IT  EXISTS,  THIS 
ROUTINE  FAItS  IF  NO  CONCEPTUAL  GROUP  EXJSTS, 

this  routine  eliminates  blanks  from  a strjng 

WHICH  IS  USUALLY  THE  FIRST  6 COLUMNS  QF  AN 

“TfJfWTlEtir ^ ~ - 


"03Tf* 

03160 

03180 

03220 

03240 

03280 

03300 


plan* 


OUTPUTS  (NOOr,L)  BLANK  LINES 


ntr 


DEFINE  I •RED  IT , L(B|LQC) f ) 


0332¥ 

03340 

03360 


■03T80 

03400 

03420 


DEFINE! 'PRINT tRTJ(R, MARK  I • ) 
DEFINE!  ^lL.6TB#'MARK2)T  ) 
OEFI«Ef IPRINTfSTCL.NO)  • ) 


03440 

03460 

0346R 


“03500 

03520 

03540 


0EFJNEMCHECK4, cG| ST.PT)  • ) 
DfF I N£  ( 1 5TMNT7N01^TRT NG)  * V 
DEFINE! '9LANK(NQ0FtL)  \) 


03560 

03580 

03600 


“eh o'  ’of  Fusrcrro^rTTEF'TNiTioNs 


"03630’ 

0364? 

03660 

“03685’ 


“*~THE  roLLUW  ‘OUTPUTS  THE  SVJTCW  C0N0TTI0NS  IS  SPECIFIC  FOR  POP-10 

* AND  FPP  TEST  CONDITIONS 

• SWITCH  CONOITJOn  OUTPUT 

!$(REAOiI 


. „ TOTTDTSWrOFTT 

.-Vo*?  >:■» 


■-•V  ? MmJ  . ; 

■ h* } •• 

* Xr'-  ■ *r  -; 


03700 

OJTP  If 

z 

Dupic  SSiei  nyo^t 

*672* 

DJTP'M 

X 

DUPU’  ’«33>  SWITCH  CO  U 1 U 0 

*61 4* 

• OJTP  »T 

c 

auPLC  njoL(  t.i  ,ao> 

*6  7b* 

OJTP  *T 

X 

•bwITCH  C'M’MTnNS  FNT£0£^  rRfth  * SVCf>N!>,FR','H 

*676* 

output 

s 

0*820 

^DuTP  »T 

X 

•CO'icrPTUiU  C°OPP  PifUHFTFRS  *RF  .» 

03820 

HUTP  IT 

X 

03840 

0JTP  »T 

z 

•**X  x • CJ..MAX  • C^O  'P  Slit  FArTf>R  IS  » r&,J»I2r 

03860 

OuTP  ‘T 

z 

0386^ 

nuTP  »T 

z 

* TW£  Fm.lOtflvU  SWITCHES  iKF  OFF 

03VkJ0 

NUTP  IT 

Z 

N S 


»•»•  * 


0392> 

*694* 

0396? 

*4*0* 
*4*2* 
*4*4* 
*4*6* 
*4*6* 
*410* 
*412'* 
*414* 
*4160 
0418? 
*476* 
7422* 
*424* 
0 42b «i 
*“*4?s* 
-Cr  0430? 
°°  0432? 

0*3*0 

*436* 

*436* 


output  z L'HroPM.S^nf-r)  'FURfiAT  PRINT  *ITn  10* 

?UTPUT  s £“*(rG.SW,OFF)  ’CO^CrpTUAL  GPO'ips* 

"OTpni  s E?(OECfS*f  OFF)  ’HL^LARATIvr  SopT  TO  BEGINNING 
^jTpnr  s L'M  I:;SNO,S*,QFF ) fl%,UFNT  STATthENT  VUMBFR*» 

output  s L^c^u.sw^opr ) »no  grouping! 

Output  = E?<Sr«FGOTc,$u#of rj  •space  refore  transfers* 
output  s £0(TtfNls*,oFF>  • transfer  groupings* 

OUTPMJ  s EO( Tu.SW.OFF)  *10  GROUPING* 

MSC  - 6LA*Kf3> 


Ot^C^I^TfO'*  op  rt#T  ARRAYI 

SI?E  is  CCMAX  9Y  5 (CG,MAX,5)  5 PARAMrTPRS  ARE©* 

1-  STATEMENT  ,\»f«qLP  (o  COLUMNS) 

7-  L*»\r  WH«0UT  STATEMENT  NUy0FR  (7-72,  TRIM) 
a-  T V?F  < IOf TR,Hl,nL,0«t AS.FO) 

«-  1-  6K I ° PLAN*  LINE  BEFORE 

?-  S *\P  LINE  AFTER 
3-  SKJP  LINE  before  AND  AFTER 
10  -»  BEGIN  CO  GROUP  BARKER 
: 72  - E^D  CG  GROUP  MARKER 

•>-  indentation  distance  or  degree 


*•  PASS  ONE  OPERATIONS 

•»••••••#••»••»•••••«•« 


ThTS  ROUTINE  READS  TME  ENTIRE  INPUT  FIeE  IDENTIFYING  ANO 

^t^m^lttd^mats  and  declaratives,  formats  ape  Placed  in  a table 

named  f FORMATS*  ACCORDING  to  TMEIR  format  NUmBERS  (REFERENCED  PY), 


0442? 

P444F 
~*4467* 

04460 
04500 
S4! 

0454^ 

04560 
“ *45*0 
04600 
04620 
04640 
04660 
04680 

~T4T*9f- 

04720 
04740 
— 0T7** 

04780  * EXTRACT  COLUMNS  1«?6 

04800  LINE  LENC6)  . LAPEL 

— *4*27 nlwt  i~k*zr  = 

0484ffl  INDET  « 5T«NT , NO (LABEL) 

04860  * AT  TW|S  POINT  LABEL  CONTAINS  THE  STATEMENT  NUMBER  IF  ARY  DEVOID  0*"  BLANKS 

~‘IT4B80 — "^WHTLT"NIT^T  CONTAINS  COLUMNS  /•  80  TTR JMED  PJGrfT)  OF  THE  INPUT 


TgF^TTT  Statement  TRANSFER  one  LI^E  OF  DATA  <*0  COL>  FROM  TME 
INPUT  FILE  <TNF>  TRJHS  EXCESS  RT  BLANKS  ANO  PUTS  IT  IN  LINE 
AN  END  OF  F JLE  CONDITIONS  CAUSES  A TRANSFER  TO  •PASSTwO* 

READ! 


L|N£  R 1*7 


INCREMENT  LINE  COUNT  BY  ONF 

ur*zr 


TF(PASSTRO) 


LjNEC 
CQPY  LINF  TO  NLINE 
NLINF  a LINE 


♦ t 


c 

r. 


94900  « 

94920  « 

04940 
94960 
04969  * 

*9*3*  ♦ 

09940  - # 

09089 
09100 

*9tf* 
05160  * 

"■05180 

05?08  r* 
05220 


?$***?  * g^cs*  t?  this  is  a tormat,  by  pattern  hatching 

TF“JT' 5" vu r-I-njWKn  TRANSFER  to  0EC.*5EAFCm 

NLTNF  ’FORMAT!  IF(0rC, SEARCH) 

increment  FORMAT  COUNT  8V  ONE 

FRM.CO'JNT  * 1 

STORE  C0LT-9B  ITRTMMED)  WHJCH  IS  THE  FORMAT  |N  THF  TA8LF 
•FORMATS'  REFERENCED  BY  ThE  FORMAT  NUMBER  (JNOFX) 

READ  ■ST/rTtMERT-TO»  HURE  INPUT  ' 
F0RH«tS<lNOEX>  • LINE  I (R£AD1! 


N^INE  OEC,R 

INCREMENT  M£«i COUNT  BY  ONE 

OEBi COUNT  « D&C, COUNT  ♦ I 

SAVE  DECLARATIVE  in  ARRAY  OECi,AR5<0Ee,CQUNY> 

OECU*RS<OECtCOUNT>  5 LINE  »(R£AD1) 


NON  DECLARATIVE  CD  TO  HEAB1  TOR  MORE  JBWr 
IF  I READ!) 


*}  & v>4  &■  w-»'  * v S 

- T- 


05320 
09340  & 


9W&W9T **  T't'f 


ON  is  NOT  REOUIREO  and  IS  DEPENDENT  ON 
W“JTJ 7*S"  ( TCFE NT|  FJC A T JDN  BAUCH)  ” ' 


SHI ^ . 

«... -1 

09440  PASS. 2 O.LJNE  * "»ppf>  * COITION  DUPLI*  nj2i 

OUTPUT  » ONLINE  EDITED  LISTING  Of  f<LC  ♦ FjLCVNAHE  * «QN  ON  1 PATCH 


OUTPUT  t>  OUPLt«4*fl?0> 


T?t’ 


# 


10  -s  ' OUTPUT  « 

— 0554* i 

09960 
09580 

05630  *«***•**••**»•***•••**•**••»•*»*• 

00620  40*  PASS  TNO  OPERATIONS  resin 

B5640 

— 05*6*  ' A ‘TUT  POLUOWINg  ST»TEMTnTS  (TH»Q  2*40)  ARE  StTBQL  DEPENDENT  “THEY  FUNCTrON 
0568P  • TO  REWIND  THE  INPUT  FILE  SO  IT  CAN  BE  REREAO  BY  PASS  T“0 

09700  P*7  REN|NOtF!LF|NAME) 

siuttiVtiwh' 


- s* 

H 


T — T 


lf)61  “ • f 


fJPOYIUNF’, FILE. NAME) 


IF(ERROR) 


Si 


0578* 

09800  • IF  THE  QEC.SW  IOECLARATIVE  PRINT  BEGINNING* 

09820  • IS  OFF  THE  OECLARATJVeS  ARE  N()T  PRINTED  BY  THEMSELVES  AT  THE 

09840 4 REEJNNTN6  Of  ?H£  U'lTPUT  LfSTTNC 

0M6R  • - v ' ": 

09800  • THE  FQL£OHfN0  RATINE  LOOPS  TO  PRINT  ALL  QxclaPAT J V£S  IFRQm  1 TO 

'WWi — ’■*  DEr/cO'UNT’FiiDM  the  ofclaps  t 

09*20  • 

•9*40  MJSC  0 EOIDEC.SW.OFF)  ISIFB.ST) 

*%  ' 


*9*9# 

BJPP^OU.T, 


06040 

06068 

06000' 


— I 8 I * 1 

TirPTPPr'i'triT, DEC, COUNT!  CCCC*RS<I>  TSniECOUNT.AOl) 


A BLANK  tw 


•4*8^:,- 

a 


M&o<*  But.nevs  Fshm 


_ 


r 


*610* 

*612* 

F614* 

*616* 

061b* 

W6Z89T 

*6?2* 
*6  24* 
*626* 
*626* 
*630* 
*632*  ~~ 

06340 

*636* 


Tnr  MurFFK  4»»sT  he  flttw  PH10R  TO  ENTERING  THE  MAIN 

UPTRITI^AL  ^ECTIOV  Of  PASS  TNOV 
STATEMENTS  4*1^  - 4040  00  THIS, 

„ rlU  BUFFE* 

b!**i  I • » ♦ 1 

^Enj  r , u ( i > if  <EPROR) 

*jsc  « eo<i,o&7haio  iriF#tmT“ 


*6400 
*642* 

~ *6*44* 

*646* 
*648* 
*65F*’ 
*652* 
0654* 
W56*" 
*658* 
*6600 
V66^P 
0664? 
0666? 
0665? 


PECJW  "AIN  OPERATIONAL  SECTION  OF  RASS  TWO 

tssume'  were- buffer  j s- toll  ^d  begin- cycle-' 

CHEC*  PUFFFS  FOR  CG  IP  SWITCH  IS  ON 

IF  CG  S*ITrH  is  ON,  THE  BUFFER  WILL  BE  CHECKED  FOR 

T-ruTrcEPWit  CROUF  BTTCHEC**,*$«'  ROUTINE,  IP  C5  SWJTQff  If  OFF 

TRANSFER  TO  VO, CO 

HW.TG  nisc  » E0tC6«SW,8FF>  lS»NOjCC» 


ui  0670? 
° 0672* 
"*6T4iar 
06760 
*6780 
“IIBT 
*682* 
*684* 

0613  $TT 

*688* 
*690* 
— *F9T*~ 
*694* 
06960 
— 069B*- 
*7000 
*7*20 

— vrrwfir 

*706* 
0708* 
— 07100“ 
*712* 
*714* 
*7l6* 
*7180 
*720* 
— *7^2* 


ECOUT if IN 


norpuT  * 


■ 


>_v'.V 


■■  ?»•'>  >■  >:4 


■i  ;?• 

i 


WEFT  STATEMENT  C«LtS  CH£C*«fCG  {IGNORE  MISC) 

IFNO  CONCEPTUAL  CROUP  EXJSTSWTHE  RETURN  WILL  CAUSE 

MJSC  « CHECK4,CGtH|SC>  IMNP.CC) 

AT  THIS  POINT  WE  KNOW  THAT  CHEOM.CC  FOUNQ  A CONCEPTUAL  GROUP  ANO  MARKFO 

tts  t^thnning  pirnrrnnre'TNnixc  TDiNrw  buffck  tst  .ft,  ewdtft) 

now  SAVE  I')  PUFFER  PARAMETERS  TO  HARK  CG  WHEN  OUTPUT  OCCURSV 
'MARK  C5  RFC  I WITH,  TNI5  TWTWB'  

m,T<ST,PT#4>  * 4» 

-^-T<F^  t^T,4>  ,-yj ; 

NOW  CALL  PPJNT. RTJ  TO  PRINT  THE  PART  OF  THE  BUFFER  CONTAINING 
THE  C0NCEPToAl~5PUUfr,  TITTHIS  TTa5E  liE’SBTPT  ARTTRrRTElT  ~ " ' 

THF  REGAIN  STATEMENTS  TN  fWE-  BUFFER  WJLL  BE  ROVED  T 0 THf  TOP 
“JSC  « P«INT, RTj(ENp,PT) 


v-i-'S,.' ' ■ 


— 


CALL  FILL.p  To  REFILL  TO  BUFFER  PROM  THE  ENO.PT 
RISC  « FILL,R(ENO,PT> 

■TER  CaLLTNBTILL.B  HE  RUST  CHECK  TO 


BECAUSE  AN  EN0.0F.F1LC  WAS  REACHED  DURING  INPUT 
•IP  THIS  IS  THE  C\A£  TRANSFER  TO  FIN, OUT,  ELSE 
BEGIN  CYCLE  A G A l N * BY  TRANSFER I NG  TO"  CHT,  CC 


RISC  9 LT(B,S12E,C.G,HAX) 


»F<CHKtCGJSCFIN,OUT) 


0724B 

P726R 

-V7TBW 


• NO  CHECK  FOR  CC  OR  NO  CC  SO  PRINT  ENTIRE  BUFFER  BY  CALLING  PRJNT.RTj 

NO, CP  RISC  * PRJNT ,RTJ(CG,HAX) 

__ 

• IF  LAST  TJME  BUFFER  »aS  FILLED  AN  ENO  3F  FILE  HAS  ENCOUNTERED  DURING 

• INPUT  THE  BEXT  STATEMENT  HILL  CAUSE  A TRANSFER  TO  FJN.OUT 

•- 0 THERM 1 ST" TT'STEL  TRANSFER rTlT'CAVLrB  

• 

-HEFTTT 


■Rise  * r^,sprr,cff,RTX7  mcAULTgi 


INPUT  C 


COMPLETED,  NOW  PERFORM  PRINT,‘RTJ  FOR  REMA1M0ER  OF 
f^SJTEJ  THEN  "TRANSFER  ~TB“7!N  TS 


rtf  =►» 


Moor*  fenmeti  Form*,  Me 


07300 

07320 

P7JT0 

07360 

0738P 

074?*" 


• FINAL  O^TPTT  THEN  ENP 

MNjPyr  *ijsc  i pR|Ni,*T4«».S!*EJ 


07420 

07440 

-fiTr&r 


PACtFB 


07480 

07500 

07T25 

07540 

07560 

07580 


07600 
07620 
“07640  ~ 
07660 
07680 
"07700“ 
0772F 
07740 
0 7760 


UP|M»> 


REFILL  THE  BUFFER  by  CALLING  FILL, 3 THFN  RECVLE  TQ  CHK.CC 

Mysp  , nuL,if#v«iir»  KCRfc.ecr- 


• •••••••••••••••••••'it** 

»Li  pone  so  print  a blank  line  ano  terminate  program 
WITH  TRANSFER  TO  E^Q 

« mewt 

M*7?Tii¥Ton#*  #«*  # »**»*  « •••••••••  


••••  FUNCTIONS  for  program 


•••••• 


RCP1T#L  LINE  4 INF 

NlINF  • LINE 

S*WCBTP>  * I 

nunf  *c'  iF<NO,trOM»ieWi 


TFTFRETURN) 


*7700 

07S00 


m,T<R,L0C,3>  *.*C0»  T *ANC«0R  « 0 
V^T.LOC,2>  « LTNC 
NO. COMMENT  LINE  LEN<6)  jMjiT^ 


1MOEX  » STNNT,NQ(LA 


f,  : 


,-4.-1 


3l..' 


. . A— 

».  ' ■ 7 . 

* -V. 

07840 
h-  0766P 


07900 

07920 

07^4P~ 


m,T<R,LQC,1>  * LABEL 
M,T<n,L0C,2>  * NL |NE 
M,T<«  L6B,4>  c 0 - 


07960 

07980 

'06080 


06020 

08040 


TSIT.00  NUNE  ’DO* 

^T<ff7iw,^FT~rfrcr* 

m I SQ  p EOIOO.SW.OFF) 

M,T<B,L0C,4>  ■ 3 

Indent  F'TWreT’TTNOENt 


«S(RE,EN) 


NLlNF  BREAKINUMBCTSI  6PANINUMBCRS)  , no 
NO  BREAKTNUHBER5)  * 


V- 


— vmevr- 

98?8'* 

0810? 

TTJ0*  TQP  1 

ST*C*<TOP>  » NO 

• 

MRE.EN) 

06120 

§8140 

08160 

ISlIiIO  NLINE  lO.P 

M#T<8,L0C,3>  e MO’ 
MISC  s EO{IO.SN.OFP| 

Tff ISJTjTR) 
I5(RF,EN> 

9618? 

082B0 

08229 

M,T<m,l0C,4>  g x 

• 

ISIT.TR  nlINE  T«n,p 

~ HREVEWF 
IFC|S|T,F0) 

08?40 

*8260 

08280 

A|T4B|LD6(47  0 MR’ 
M|iC  0 E®(TRN,SW,0Ff» 
M,t<§,L0e|4>  c 3 

ISfRF.ENT 

0830? 

96320 

08340 

nliMe  ’Co  to’  ~ , 

M,T<B,L0C,4>  r a* 

• 

1 P ( RE .ENT 
HH.CN) 

98369 

tint 

99400 

’i»iT49n  >*«e 

# ’V  • y*  - £■/'•*• 

iF(JSIf,OEE) 

M®CVfN| 

— 08420 
08440 
0846" 

If lS»AS  H § T | L CTfT# 33  p *4Sf 

M i T<5 , LQC 1 3>  • i AS ? 

» 

i wr;cin 

fRE.FNI 

06403 

IsIT.M!  WflNE  M|,P 

1 FT  MTS.  AST 

'tui.Oj  U4wtng  •iqg.v 


r 


pa  50* 
0B52P 

08560 
08580 
~ -0S5OTT 


MtT<^ltQCf3>  ? IMP 


MRE.E*) 


Tsrm^rc 


1^4 1 NE  DEC/P 
H,T<RlL0Cf3>  * 


»ne* 


irupnw 

* (*E,£M) 


08623 

08640 

"PTBTTS^ 


PE.EN 


^|T<R*L0n^>  * INDENT 
EQf  THP , k)) 


P866* 
08700 
PBTZT 


TDEWT  CUa^EL  i 


* ) 


ISCRr,END) 


!0ENTCRTACK<T0P>tSTMNT#NO<LA9EUi 


IFCRE  tENO> 


08740 

08760 


06800 

06820 

TTBF^rrr 


INDENT  tlARGJM  * 

TOP  * Top  * 1 

CTTRTr<B,iOC,  0 1 1 r 


0886* 
08880 
15  8 9 BP 
06920 
08940 
1E95T 


~~  irt^itow' 

^,T<oftOCt4>  c 2 !<*£#END> 

RE,C0N6 P.U^IOC^  * h«T<B«lOC,4>  ♦ 1 

RE.EMp  0,K  * 6 


Mft£*v*N> 


— P7B2B 
0V04P 
K 09060 

09100 

09120 


P9?8P 

09300 


0946* 

09480 


09580 

09600 


09640 

0966* 

T59680‘ 


08980  PfUNTfPTJ 
09000  PR, API 


l * 0 
1*1*1 
CTUtB.MiRK) 
PRl*TtST<l> 


tSilfTpW 


ICPR.m* 


# 

PHECK4,C6  CTOfPT  * CG,S1«  • R,SJIE  / J.0  * 


09HH 

1TT7CTWT  s 0 1 

P9l6?i 

I * * 

0918^ 

C4.AP1  1*1*1 

09Z0PJ 

— CTTTTF.yrZE} 

09220 

IDENT(M,T<!,3; 

0924P 

TR, COUNT  ■ TR 

tnx^jtWT 

«F<C«,C1* 


.3TCTM 


trtCTjtrri 


P4.C2 


lO.g^J^T  * 1 0 1 COUNT  ♦ 1 l(C4tAPl) 
!0ENT^fT<I,3>,  1 ASM  *F<C*.AQl> 

tstcdunt  'TTnrt*cDUsnr  - <r r ttc*7*pit 


■09320 

09340  • 

09360  • 

09380 — cttekb — rrp-r-irrTT* , TQBNTTrrcr.-rn^iRf  isrc?rrn>owrr 

09400  UP  * r,T(  IO#r0UNT,CTO,PT>  M0f  |5(rGfF0U^0) 

09420  TY P * PTCAS#CO»»NTf CTO,PT>  *AS»  1 S < CP , rOUNO ) 

0944P  * 


ST t PT  » 0 


I (CHK|FA!t ) 


19610 rGTFPffWD  — r *~F 

09520  CG4,AD1  1*1*1 

09540  IDENT(3fT<I#3>#TYP5 

09560 


TlTFTi  T 


I F * CG4 , A01 ) 


I * Q.SUE  * 1 

1 - 

I0ENT(m(T<I,3>#TYP)  SF(Cr,4fMl) 

END , °T  * I 

rrrnr TRUCES s » BT,PT  EMD^PTKFETVPNl 


— 





M ©•»•  tutineii  f 9*mt, 


12100  • 

12120  •*  REVISE  ▼«  ACCEPT  SJj/QFF  &*  SINGLE  LINE  SELECT 

T2140  m * 

12160  S«CAPO,f!LE  TTT  * 'E^TCR  CONTROL  SWJTCM  FJLE  NAME* 
12180  NLINE  * TTT  

if(ERROR,SWCTLF) 

1Q,SW  ■ I NSW  if (ERROR, SWCTLPJ 

P2Wg®F,S“  » INSH  »f (ERROR, SVCTLH 

CGOU«P,$w  ■ INSK  If  (ERROR, SWCT4PJ 

CG.HIN  ^ INSM  » f < ERROR , SRpTLE I 

Wft.RJN,*)  IffSM.n 

1234*  CC,HTN  * 3 

12360  * JNSU  if (ERROR, SUCTLPJ 


12220 

12240 

1Z?G* 

12280 

12300 

T232r 


"12380 
12-100 
1242R 
T2«3TO 
12«60 
12480 
~ 12500 
12520 
12M0 
1286 
12560 
12600 
~ I262ro_ 
12640 

VJI  12660 

vn'  «WP" 

12700 

12720 

1274« 

12760 
12760 
— ROTO” 
12820 
1284" 
— 12883' 
12880 
12900 

" 12920 
12948 
12460 
12980 


SW,2 


Ey  ( CO  1 fVi } 

CC,H*X  « IP 
Stir  « ins* 

TWCffi 

T 1 

SW  • !NS» 

.,t»tT2"IN5« 

00, SW  » 1 M»P 

TRN.RW  a (NSH 

I7SR~«  17IW ” — *~~" 

C6,S0  ■ I NSH 
INSN«,S*  s JNSH 
■8FWTC0T(17SR  «"Tli)SW 
S«CORO,f"OP  • 'HIE  NAHEOI  » 


»f(  ERROR,  SRCT13-) 

-"Wi8v;»r^ — 


If ( ERROR , SWCTEf } 
IFI  ERROR, SWfiTLFJ 
If (ERROR, SWCTLOJ 
if ( ERROR, SWCTuP ) 
ir<ERR0R7SV»CTLPr 
if(EPROR.SMCTLE) 
If (ERROR, SWCTLfl 
"ITtERRORVSRCTLRJ 


OETACH( * INSH’ » 

1TT?C,HAX,BT5i7Er 


NLINE 

rrio.Ti 


OUTPUT  * 'ERROR  IN  CC.Hax,  OEFAULT  0 ' M»f 

.1(0,7) 


C6,HAX  f 8, SIZE 


MROR*fkCTLr TTTT^ERRBRlfAS  TJCCORREO  IN  SVJTCH "CONTROL* 

TTT  « »ftCE  READ. PILE  OOES  NOT  E*JST  OR  AN  l 
TTT  a 'END-Of.riLE  WAS  ENCOUNTERED  DURING  SEAReHl 

rTT  • •fOR  SHlTCir  cORTROL'VALOES;  OEf  AULT  "VAtursi 

TTT  » 'RIEL  RE  USED  fO*  SWITCHES  NOT  YET  SPECIFIED,' 
TTT  « I (0, F ) 


13000 

13020 

13848 

19860 

19888 

13108 

13120 

13148 

13160 


SNCARD.TTT  tty 

NLINf  ■ TTT 
NLINF  'FORT" 


SM.A 


?W,I 

sw;c~ 


sh.o 


FORNVSW  « OFF 
NLINF  *OEC' 
HECtSH  # OFF- 

NLIW  *00* 

09, fW  * OFF 
NtlNE  ’TRN' — 
TRN,FH  3 OFF 

nline  *jo» 


'ENTER  SWITCHES  THAT  SHOULD  BE  OFF 
If CSU, A) 

IflfW , g J 
IF(SW.C) 

— nrrw.Tj) — - 


lf(SW,E) 


13240 

13260 


8W.9 


INF  T JNSNCP" 
INSNO.Sw  f Off 
NLINE  'SR8FCOTO' 

ssmvfN  »w 


lf(SW,H) 


_2_ 


•V 


i#f|g 

• f-h&i  - 

: •.  v ’’•Si’-  \.<4 
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APPENDIX  B 


CONCEPTUAL  GROUPINGS  PROGRAM  FOR  FORTRAN  (GP-F) 


6.  SOURCE  FORTRAN  PROGRAM  LISTING 


UNGROUPED 


I HAlMTCMAKCE  PROGRftK-'lHG 


R 


c 

C THE  I/O  OMITS  ARE  AS  FOLLOWS: 

C 1*LIM£  PRINTERtERROR  MESSAGES) 

C ?«OLD  MASTER  EMPLOYEE  PAY  RECORD  TAPE 


C 3*NEH  MASTER  EMPLOYEE  PAY  RECORD  TAPE 
C 4«CHECK  PRINTER 


C 5'CARD  PUNCH  FOR  NEW  PAYROLL/TIME  CARDS 

C 6»CARP  READER  XQR  EHPLOYEE^PA 

c 


52.$S3.DE1,OS2.PE3.P1.D2.03.EhP2>V,C 


TF 


:gCRJTU>ET2  ,ET3.SSU,SS22>S|33 
(fJivrsS'H-itMPT  , 5>  »nEl>0E2#DE3*Ol#D?»O3 


SMEHt-S 


(B(J), J*1,13> 


27. 


0»«t 

COT rw 


»ga8:Bt  WMMitf: 


C,ETlTtT2>ET3>SSU.SS2?>SS33 


Q;*«»  tO  TO  -4* 
l 25»3P.t35 


(N< J>» J*l»5) 

.AMO.  C .’JE.  1.0)  CO  TO  9B0 


..S.Slf.SSll 

S$2*SS22 

SS3»SS33 


* 


v. 

i 

i 

■ i 


-26 


DO  26  J*l«  5 


l»ETl 
-Pf2*£T2. 


OE3«ET3 

0A«g. 


02*0  • 


liTiAii) 

8<3)*0. 
B»4).gy 
B(5)«0. 


B(6)»A(5) 

R(7)«A<3) 

B(9>»AM) 
B(f  )*A<2) 


B(1U*0, 


B(6)»A(5) 

3?  IF(T(?5,Eo.C.)  CO  TO  38 

> : r * ■ \ 


L- 





Mot  **  ftotintn  fttmt,  lr>« 


r~~ 


n - 


R(l0)sA(2> 


38  I F ( A 1 3 ) ,E<3.0.  ) GO  TO  30 
R (7)s A ( 3 ) 


30  IF(A<4.)  .EJ.C.  > GO  TO  4^ 
8(9>*A(4) 


IF (Hw.LE.4fl. ) GO  TO  43 
GP«8(1)*40.  ♦ (B(l)  • 1.5  »(HW-4fl,)) 


GO  TO  45“ 
43  GPsB  ( 1 ) *Hr-' 


45  I F ( V , N£ , fl , ) GO  TO  *.0 
B( 13) «B(  l'3)  *2 . 


s*fl, 

GO  TO  90 


5C  IF{ V.EO.l.  ) GO  TO  60 
B(l3)»B(13)-HL 


IF  (U(13)  .GE.t).  ) GO  TO  70 
5=(HL-ABS(B(13)  ) )»M1) 

3 ( 13 ) sfl . 

GO  TO  90 


60  B ( 12 ) =B ( 12 ) *HL 

IF  Q ( 12 ) .LE  ♦ 8.) . ) G°  TO  7P 


D*B ( 1 2 ) ■ 83 ■ 
GsHL-0 


S»G*A(1) 

3(12 >«80. 

GO  TO  90 
, . 70 5aHL»A ( 1 > 


CD  90  GP=S*GP 

° FINC=(GP-(13.»B(6>  i i«.14 


B(3>*6(3)*F1NC 
100  B(2)=GP+H(2) 


IF(B(2)  .LE. 480.0. ) GO  TO  105 


v_- 


r tun.u, 

GO  TO  110 

105 

F 1 CA  = GP» , 33626 

lie 

B ( 4 ) *F I C A*t)  ( 4 ) 

IF(8(2>  .LE.510R.  ) GO  TO  Ur> 

SOI*0. 

GO  TO  123 

115 

120 

SO  I * , 31»GP 
B(5)=SDI*B(5) 

IF(B(5) .LE.51. ) GO  TO  125 
B(5)*51. 

125 

B(ll)sB(ll)*B(10) 

IF (8(7> .EG, 3. > GO  TO  135 

B(8)*B(6>«-8(7> 
BONDs , 75»B (9 ) 

IF (BOND.LT ,B( S) ) GO  TO  133 
GO  TO  135 

130 

B ( 8 ) *B  ( 8 ) -30)40 
MB0MD«B(9) 

GO  TO  140 

135. 

WBONRsO , 

140 

15P 

0»(Gp-(FJ\C+F IC A*SO I *B ( 10 ) ) )*WROND 

•WRITE (3, 5)  EHP.SSl.SS2.SS3, (T( J), Jal,5) ,DEl.DE?.OE3.Dl,02*03 

HRI Te ( 3. 7)  (B( J) , J*l,13> 

WRITE (5, 17)  EMP.SS1.SS7.SS3. (T(J), jsl.5) 

WRITE! 4, 18)  (T(J), J=1,5),SS1,SS2,SS3,0 
I F C C .EO.  l.fi)  GO  TO  23 

* 

* 1 







M#«r*  6uvn*»j  Form*.  Inc. 


_ ..M3-  wFMTgg,q>;i)  chp.  (t(j>  . j»i.g>..FHP2.  <w<  j> , j»i,5i. 
O STOP 

7 FORMA  T ( 13F6 . 2 ) 


22  FORMAT ( 14,2F4,2»2I1»3I?, 13 » I ?« I 4 > 

23  F0RHaT(5F6.2.5X.5A5) 

17  FORMAT ( J4.16X, 13, 1 2 . I 4/35X , 5A5 ) 

18  F0RHaT(5A  5 .314. re. g) 

5 FORMAT (414.5A5.6I2) 

931  FORHaTCIPH  ERROR--  , 1 4 , 2X , 5A5 , 4X,  1 4 . 2X . 5A»> ) 
END 


fS 


=1 


' 


'I 


1 


EqP  ON  DSKA'ii  ICS . i 
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APPENDIX  B 


CONCEPTUAL  GROUPINGS  PROGRAM  FOR  FORTRAN  (GP-F) 


7.  SOURCE  FORTRAN  PROGRAM  LISTING — 

GROUPED 


) 

) 

i 

1 
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PART  III  MAINTENANCE  PROORAMVING 
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I 
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* 
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,o  n 


! 'TECEP-  FfiP.SSi.SS?,SS’?.Ptl7bt?.lt^.,)i,0?.r3#EMP?,V,C 

.1 1.TECSM  r T l .JLU.F.  T 3 . S3 1 1 ,SL22j SS13 

DIMENSION  tidj),  T(5).  A ( 7 ) • W(5) 


C PAYROLL  program 

C Trir  i/0_UNIT»  ARE  as  FALLOWS: 

C 1*LL*IL  PRINTER  (ERROR  MrSSAGES) 

C 2 = ''LO  MASTER  EMPLOYEE  PAY  PErO^O  TAPE 
C 3=  IIP  master  LMFLOYEE  PA_Y  RECORD  TAPE 
C 4=CHECK  PRINTER 

-C_i?CARlLJ,U’JCH  U»«_is£W  PA*RQLL/.miE-£ARPS- 


6=capo  rearer  fop  ehployee  pay  cards 


_ XL  pEA0(2.5,EN0=9)EMp,SSl.SS2.SS3.(T(J).J=1.5).DEl,PE2.0E3.01.D2.03 
5 r0RUAT(4I4,5A5,6I2) 


READ { 2 » 7 .EnDs9)  (B( J) , J»1,13) 
7 rORMAT(13P6.2) 


irtOl.ECl.t. ) GO  TO  2£? 


* TRANSFER  • 


0 = 0. 

GO  TO  15P 


« TRANSFER  » 


2?  RLaO(6.2 2)  EMP2.Hh.HLrV.C,rTl.rT2.rT3rSSil[ SS22  r SS33 
22  FORMAT!  I 4. 2F*. 2.2 1 1.3 1?. 13, 12. 1 4) 


READ(6,23)  (A< J) , J=l,5> , t!)(J).J*1.5) 
23  FOR  M A T ( 5F6 . 2 » 5 X . 5 AO ) 


lF(E«P  .NL.  EhP2  .AND.  C ,oE.  l.o)  GO  TO  900 

* transfe'r  * 

iTTCTEO.?.)  GO  TO  40 

• TRANSFER  * 

lTcC^2.)  25.30,35 

• TRANSFER  • 

20  EMP=EMP2 


SS1  = SS11 

SS2*SS22 

SS3*SS33 / 


00  26  J=l,5 


2J, T<J)=W( J) 

OElsETl 

0E?s£T2 


0E3=ET  3 

Dl=2. 

02=2. 

03=2. 

JO  = l • 

B(t)=A(l) 


M»3<«  Bjfinrit  fVmi.  Ir« 


B(?)=0 

&f3)*0 


' 


i , 


t 


B(4)=0. _ _ 

{HSJse. 

B(6)=A(5) 

B(7)=A<3> 

B<e)*e. 

BC9)=A(4>  . 

B(10)=A<2> 


: 

Bd3)=r. 

GO  TO » XRANSf-£R_» 


33 

01«£T1 

02=ET2 

V 

D3*ET3 
GO  TO  40 

• transfer  * 

3*5 

IFl All) .CQ.6. ) 

G* 

"to  36 

- -i. 

• transfer  * 

165 

36 

Btl)sA(l) 
IFIA15) .EO.B. > 

or 

TO  37 

_ir AfcisrrR  # „ 

0<6>=A<5> 

37 

JFIA12).EO,0.) 

Gr* 

TO  36 

• transfer  * 

38 

Blli)=Al2> 

IF(A(3).EO,e.) 

GO 

TO  39 

• TRANSFER  • 

B<7  )*A<3 ) 

39 

IFIA14).EQ.0. ) 

Gn 

TO  40 

• transfer  • 

40 

B(9)zA(4) 

IFlHW.ue.40.  ) 

GO 

TO  43 

• transfer  • 

Gps0  < 1) *40  # ♦ 

(Bll)  * 1.5  • (HH«4™ , ) ) 

GO  TO  45 

• TRANSFER  • 

43 

GP=B < 1 ) «HW 

45 

IFIV.NE.0.)  GO 

TO 

50 

* / 

* TRANSFER  • 

8 ( 13 ) *B< 13 ) *2 . 

GO  TO  90 

* transfer  * 

5 ft 

I F (V.tQ.l. > GO 

TO 

60 

* TRANSFER  * ...  

B(13)bB(13)-Hi 

if1  ( 6 ( 13)  .GE  > 0 . ) GO  TO  70  • TRANSFER  • 


S*(HL-ABS<6(13> ) )*A(1 > 


i 


j 


: isu  — 


n<i3»=e. 

GO  TO  90 

ft 

TRANSFER 

* 

60 

R(12)=H(l2)*nt 

IF(3(12) .UE.nO. > GO  T0  70 

i 

• 

transfer 

• 

OxO(l£)-F>3. 

GSHL-D 

5=G*AC1) 
B<12>*8f . 

CO  TO  9d 

• 

TRANSFER 

ft 

73 

S=HL*A(1) 

A 

93 

GPsS*GP 

FlNC=<GP-<l3.»RM>>)..14 

. ABO 

B(3)*B<3)*FI NC 
bC2)xGP*PC2> 

lF(b(2)  ,UE,4865!. ) GO  TO  1B5 

• 

transfer 

ft 

FlCAsO. 

GO  TO  11? 

* 

TRANSFER 

ft 

~CTV 

cr> 


IBS 

-lltL 


FICASGP*. 33625 

B(4>griCA*i-:(<> 

IF({><2>  ,lE,5ie3. ) GO  TO  115 


• TRANSFER  • 


SO!=0. 

GC_T0JL2? ' • _IfiAJslSFER  • 


115  sDis.ei»c-p 

123_ 6(5)=SI»I*6(5) 

l F < 8 ( 5 ) . LE . 51 .)  GO  TO  125  * TRANSFER  • 

“b  ( 5)~s5T7 

125 B(ll)gB(ll)*r  (13) 

IF(t(7)  ,t3. 2,  ) CO  TO  135  * TRANSFER  • 


B<8>=B<8)*8<7) 

80  1 J = . 75»E  < 9 ) 

IF"(aONO,Lt,'8<8) ) GO  TO'  130  « TRANSFER  • 

GO  TO  13*  ' * TRANSFER  • 


130 B(8)=B(8  )-PQ:;D 

WBOhD=H<<>> 

GO  TO  140 • TRANSf'E R_* 


135  W30nO*H. 

14? p = ( CP-(F1NC*F|CA*S01*B(10)  1 )»WBQNP 


A 

. • * 
WR1TE<3.7>  (P<J>.J=1.13> 

A 1 

7 

FORMAT  < 13F6 . ? ) 

WRITE(5,l7)  rMP.SSl.SS? . SS3 . ( T < J) . jsi .5) 

17 

FORMAT ( 14.16V. 13, I? « 1 4/35X , 5A5  > 

WRITE  (4, 18)  <T(J)  , jsi.«5),SSl.SS2.SS3.D 

18 

F0RHAT(SA5. 314, Fr. 2) 

IF(C  .EQ.  1.7)  GC  TO  2? 

* transfer  * 

GO  TO  13 

• TRANSFER  • 

900 

901 

WRITE  (1,901 ) EMP.  (T(  J) , Jsl.t,)  ,EMP2,  (W(  J) , Jsl,5) 
FORMAT ( 13H  ERROR , I 4 , ?X , 5A5 , 4 V , I 4 , 2X . 5A5 > 

- 

9 

STOP 

END 

’ -"*.r  -4.  -i 

-? — rr" 


«■ 


Z5f  OfJ  0SKA2:  ICS.o 
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APPENDIX  C 


1. 


General  System  Description  (GP-P) 


Part  I 


This  version  of  GP-P  allots  50  buffer  lines  in  all  for 
statement  storage.  LINDEX,  the  table  of  pointers  to 
first  lines  of  statements  in  the  buffer,  is 
dimensioned  at  20.  ADDPTR,  which  computes  the  address 
of  the  next  available  buffer  line,  checks  for  over- 
written storage. 

The  buffer  is  actually  6 arrays,  of  which  2 are  doubly 
dimensioned: 

PREFIX  (50,5)  contains  any  condition  prefixes,  each 

< = 31  characters,  which  precede  the  statement. 

LABEL  (50,5)  stores  any  statement  labels  (also 

< = 31  characters  each) 

TYPE  (50)  contains  the  classification:  'AST1  for 

assignment,  10,  'CAL'  for  call  statements, 

'CTRL'  for  GO  TO,  WAIT,  RETURN  and  other  control 
commands,  'STOP'  for  declarations  and  allo- 
cations, 'ON'  for  'ON  CONDITION'  statements, 
and  'COM'  for  comments. 

LEVEL  (50)  holds  the  nesting  level.  It  is  always 
0 for  a comment,  1 for  the  main  program. 

Levels  presently  range  from  0 to  9 . 

SKIP  (50)  contains  the  SKIP  code  assigned  to  the 
statement  in  Part  II.  This  code  indicates 
lines  to  be  skipped  and/or  dotted  lines  to  be 
used  in  setting  the  statement  in  its  proper 
format.  In  Part  III  the  code  may  be  separated 
into  its  'fore'  and  'aft'  components,  or  may  be 
modified,  when  more  than  one  statement  at  a 
tiitie  is  considered.  The  doubly  dimensioned 
CHCODE  arrays  contains  these  2 components  for 
each  value  of  SKIP. 


SKIP  Action  to  be  taken 


CHCODE  CHCODE 
(SKIP,  1)  (SKIP,  2) 
(before)  (after) 


0 no  skip  before  or  after  0 

1 skip  line  before  1 

2 skip  line  before  & after  1 

3 skip  line  after  0 

4 dotted  line  after  0 

5 dotted  line  & skip,  after  0 

6 precede  by  dotted  line  & skip  6 

7 precede  by  dot  & skip,  follow 

by  dot  6 

8 precede  by  dotted  line  8 

9 precede  & follow  by 

dotted  line  8 


0 

0 

3 

3 

4 

5 
0 

4 

0 

4 


TEXT  (50)  stores  the  statement  text  after  any 
condition  and/or  label  prefixes  have  been 
stored  separately.  It  allows  up  to  120 
characters  to  the  line  (but  uses  less  for  80 
column  output) . 

The  pushdown  list  is  a set  of  3 controlled  variables, 

STACK  1,  STACK  2 and  STACK  3 (STACK  2 is  dimensioned  at 
5)  which  are  allocated  and  freed  as  levels  increase  or 
decrease.  The  same  list  serves  to  keep  track  of  commands, 
labels  and  levels  for  IF... ELSE  structures  and  for  all 
kinds  of  blocks. 

Part  II 

The  program  processes  one  (1)  PL/1  statement  at  a time. 

The  statement  is  read,  analyzed,  and  stored  with  its: 

(1)  type;  (2)  skip  code;  (3)  nesting  level;  (4)  text; 
and  (5)  prefix (es)  which  are  separated. 
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Part  III 


After  each  statement  is  analyzed  and  stored  (Part  II) , 
Part  III  surveys  the  situation  to  see  if  any  output  is 
to  take  place,  to  output  if  so  indicated,  and  to  reindex 
the  statements  remaining  in  the  buffer.  When  COUNT  has 
reached  the  stipulated  size  BUFCG,  the  buffer  is  examined 
to  find  conceptual  groups  (CGs) , and  these  are  output 
if  found.  If  not,  the  top  half  of  the  buffer  is  output 
and  the  program  loops  with  the  next  statement. 


Rule  1 

Every  time  the  level  changes  that  part  of  the  buffer 
preceding  the  change  is  output. 


Rule  2 

If  the  SKIP  code  of  the  current  statement  calls  for  skip 
and/or  dotted  line  before  it,  attach  the  'action'  (as  an 
'after'  skip  or  dotted  line)  to  the  statement  preceding 
it,  and  after  the  current  statement's  code  to  show  only 
its  'after'  component.  (Note  that  when  this  rule  is 
applied  to  every  statement  in  turn,  the  code  of  the 
statement  preceding  the  current  one  can  be  only  0,  3,  4 
or  5)  . 


Rule  3 

If  the  SKIP  code  of  statement  preceding  the  current  one 
calls  for  skip  and/or  dotted  line  after  it,  output  all 
lines  in  buffer  through  that  preceding  statement  with 
that  code.  Again,  the  code  can  be  only  0,  3,  4 or  5. 

Note  that  in  Rules  2 and  3,  we  consider  the  'before'  code 
of  the  current  statement,  and  the  'after'  code  of  its 
predicessor,  and  the  current  statement  is  never  printed 
out  (unless  it  is  the  last  statement  in  the  program, 

Rule  6) . This  is  because  a succeeding  statement  of  the 
same  type  may  erase  the  'skip  line'  following  a statement. 
Consequently  the  COUNT  is  never  less  than  1 after  exe- 
cution starts.  Also,  none  but  the  current  statement  and 
its  predecessor  can  have  a SKIP  code  other  than  0,  else 
it  would  have  been  output. 


Rule  4 (Search  for  CG) 

When  COUNT  reaches  BUFCG,  a search  is  made  for  a CG. 
If  in  any  group  of  HALFCG  (half  of  BUFCG)  successive 
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statements  at  least  TESTCG  are  of  the  same  type,  it  is 
considered  a CG.  Only  assignment,  10  and  CALL  statements 
are  counted,  since  other  types  carry  punctuation  codes 
which  would  have  output  them  before  this.  Each  group  of 
HALFCG  is  considered  in  turn,  starting  with  statement  1 
the  first  time,  statement  2 the  next,  etc.  until  the 
next-to-last  buffer  statement  (the  last,  if  it  is  EOF) , 
has  been  examined.  BUFCG  and  TESTCG  are  read-in  values. 
BUFCG  cannot  exceed  20  without  changing  the  dimensions 
given  in  Part  I declarations,  and  TESTCG  must  obviously 
not  exceed  half  of  BUFCG. 

If  a CG  is  found,  the  pre-CG  statements  are  output  (no 
pre-skip) , a skip  is  printed,  the  CG  is  output  followed 
by  a skip,  and  the  remaining  statements  are  'moved  up' 
in  the  buffer. 


Rule  5 

If  no  CG  is  found,  the  top  HALFCG  of  the  buffer  is  out- 
put without  any  skips , and  remaining  statements  are 
'moved  up'  in  buffer. 


Rule  6 

If  an  EOF  has  occurred  (FINIS  = 1) , the  whole  buffer  is 
output  if  COUNT  < HALFCG.  If  COUNT  is  not  less  than 
HALFCG,  a search  for  a CG  is  made,  using  all  the  state- 
ments in  the  buffer.  In  either  case,  all  statements 
are  output,  and  the  program  proceeds  to  ENDPROG. 

Note  (s) : 

STEXT  (SOMLIN) 

Before  STEXT  is  called,  the  calling  program  must  have 
defined  TYPE,  SKIP  code  and  LEVEL  for  the  statement. 

The  condition  prefix  (es)  and/or  label (s) , if  any,  have 
already  been  stored  in  the  buffer  among  PREFIX  and  LABEL. 
(Up  to  5 each,  of  <_  characters,  are  allowed  here.)  The 
statement  text  is  in  SOMLIN.  STEXT  must  now  format  the 
text  for  output. 

FORMAT:  In  all  cases  column  1 is  blank.  If  the 

statement  is  a comment,  cols  2-4  contain  the 
characters  '/*#'  followed  by  65  characters  of 
text  if  NCOL  = 80,  by  109  if  NCOL  = 120. 

These  are  followed  by  '#*/'  in  cols  70-72  (or 
114-116) . 
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For  non-coiranent  statements  the  maximum  length 
for  an  output  line  (excluding  the  level)  is 
72-Margin  characters  (116-margin  for  120  column 
output) , where  Margin  is  the  margin  defined  for 
the  nesting  level  of  this  statement  (stored  in 
LEVEL).  The  level  is  in  cols  74  & 75  (118  & 
119) . 

If  the  statement  occupies  more  than  one  line, 
the  SKIP  code  is  separated  into  'fore'  and 
'aft'  components  (using  the  CHCODE  table),  the 
'fore'  code  is  assigned  to  the  first  line,  the 
'aft'  to  the  last,  with  any  additional  lines 
between  marked  0,  or  no  skip. 

If  condition  or  label  prefixes  are  present  they  will  be 
printed  on  the  same  line  as  the  text  only  if  their 
(combined)  length  fits  into  the  margin  before  the  text. 
Otherwise  they  will  be  assigned  separate  line(s). 
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CONCEPTUAL  GROUPINGS  PROGRAM  FOR  PL/1 


2.  Operating  Instructions 


(1)  The  Conceptual  Grouping  Program  for  PL/1 
has  been  designed  to  operate  under  the 
standard  operating  procedures  for 
IBM  360/370  (DS  or  DOS)  systems. 


(2)  Input  source  deck  is  read  off  SYSIPT 
(device  independent) . 


(3)  Control  card  information  is  read  off 

SYS00Y  (a  2540  card  reader) , and  it  con- 
sists of  7 numbers  separated  by  one  or  more 
spaces  on  one  or  more  cards: 


Parameter  1: 

2: 

3: 
4: 
5 : 
6: 

7: 


Length  of  Printline;  suggested 

120. 

Beginning  margin;  must  be  at 
least  9,  suggested  9. 

Margin  step  size;  suggested  5. 
The  number  20 . 

The  number  7. 

Max.  no.  of  characters  per 

PL/1  statement;  suggested  800. 
Max.  no.  of  edited  lines  pro- 
duced per  PL/1  statement; 
suggest  50. 


(4)  Parameters  6,  7 will  affect  storage  require- 
ments. If  parameter  6 is  too  small,  program 
will  know  this  and  cancel  after  printing  an 
appropriate  error  message. 


(5)  Parameter  7 , however,  will  not  be  recognized 
as  being  too  small  if,  indeed,  it  is  too 
small.  Missing  edited  lines  are  an  indica- 
tion that  parameter  7 was  too  small. 
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APPENDIX  C 

CONCEPTUAL  GROUPINGS  PROGRAM  FOR  PL/1  (GP-P) 


3.  GROUPINGS  PROGRAM  FOR  PL/1  SYSTEM 


BLOCK  DIAGRAM 


Output  list 
for  formatted 
source  program. 

[Optionally , 
punch  new  deck 
or  write  disk 
file  of  new 
source  pro- 
gram. ] 


GP-P  SYSTEM  BLOCK  DIAGRAM 
GROUPING  PROGRAM  FOR  PL/1 


APPENDIX  C 


CONCEPTUAL  GROUPINGS  PROGRAM  FOR  PL/1  (GP-P) 


4.  GROUPINGS  PROGRAM  FOR  PL/1  (GP-P) 


GP-P  FLOW  CHARTS 


179 


PL£DXr  : 


180 


PiBiyiT  (card.):  'Process  1 statin/ e/ it  ctd  b/ne, 

Redd,  dhd/yze,  store  u>)th  its  type,  skip  code,  nesting 
(ete/;  text,  aid  Zsepe rated)  preHxfcs) 


-FROM  PARIS 


^ mcM  t nr  ^ 


Go  • 


Prcwt  per  next  statement  Assign 

ana  update  pon/rrr  ft  buffer  errdfsdne/ 

/nap  ft  pointer  


PLFD1T 

TVi-t  Tr  ( Co^ 


182 


F3- 


Mchni 


Ru.Li 


fclxL3: 


RaU/ 


PLEj)XT  (Co.  X) 


183 


cr  I>  C 


-f  iro  **» 

Pl  eorr 


^eo.lj;  itN^uT^  *fi  le  “(ft  S6*^o.r«^<?  t*tr 
St^oCt e v»s.«  | *Hc«i  f(tO  / (ci*. 

ccr%iL  /er  l<jube*t  ) ^ o-v^ iL  He  <t“  ^ le«>JL\*vc 

K-S  «r  ft.  | n F , 


4^ 


kf 


RLAftt  L 


ReAO 

tLi'C 


C„Uek  v,^  \£AO,  X F^ELl’b  -b  ft-*., 

STti  re.  A^liille:  4‘fd'^v  L.X  ^ E"  ccrv^ 


CtA&Lii.t^  cv  (<lI?c*I  prefifies-  A(lc*vi  H^4 

jT"  c”f  e.t'-cK  , wM  «t*k  3 l cka>ro*c^«*  vr  o^rt^r-i  * f 


Le 


o-yc  ^ 


LrNtTvo.tiv  ^et*<£A*c^  bUwki  dieted. 


(jLer  u-rLw'  ^) 

r 


185 


y 


C &eTu.Atf  ) 


GrFTSTAT 


3Tsrra  •. 


$>6M>  "t;  y«A-  ( StvWv^«<c\i  Ut\«  tlfaUv-j 
\»k«Kt  <S-eWW£,  i«-K  Ltwe  . Cuts  IM  ‘K  ^ 


187 


Celled  by  GBTSAt  &>  ceteh  / input  recen  t 
ctktc  icedtn £ ona  tmUna  blanks.  am 
6dd  tttb  AJCtf&D . written  to  read  %o- 
column  input  u/ith  cidtn  m cots.  £*72. 
it  '$  detected  m cot  t,  flat  cord  up  ft  nut 
Cdrtf  With  ' m cot  t Undue*  uc.)  drd. 
printed  but  net  prices*#/  after  output, 
Mouup  celled. 

* Action  on  end  of  input  pfe  /s  debtee/ 
by  OT'&ri>  Fat  6/ocK  tn  fteorr* 
Pmi5  '/  find  return  /s  made,  to  evDtej) 


188 


/\SS/d7^  Subroutine 


189 


Ca.lVeA-  PLeDX  l ~fca  j7TCtc?si 

piCocGpltlSe  ^ ^t^XiV  , l>er>  ENiTli'l 
S ^«s-yCts  O-"^  ic  y-  -fke  ^ a.* 

y^U-sU.  lls'V.  Ntti+if'-a  level  \i 

in  c re  n>_e  nH  -A.  &c  tvnfcl.^ 


191 


i 

Vi 


^ Nctenei  Cuw\mo  ^ts  Sj,  a.C«-  '<? 

*f-ir*T  o-Httr  U.rt  u 

#ct  $ . 


192 





CTiIlC  ( CTie.LG-.CT^.L^ 


CTAlC  c*4»ei  b«t  PLettlT  4er 
CAtL  (u  , CT&1-G-  H<  si-. , 

C.TiC.i.6-  -f«<-  rt-V*«v  cocV<-«\  rt»it- 
• sVAXT  , Dff-Lfci, 

• A CftlL 

ojtcu*  .-<  eALUS ) , G-&  Tb  0-r* 

b^  Jfc-.f  «■  *■<*+*  u*'«  • 

OtL»#rJ 

x(  Y<«i  *+  fX*E  **'« 

nesli-.y  Uel  .*  i rv  *1*  V,  -«1  <«-«*•'«• 


SuB>  deCLA&e- 


f/\AlV 

Cca/1  beciA&G) 


Fi&ST  unC  cf  bCL  t»/ 
LBi/GL  (Pl/UbBK)-  LEu£L 
TJP6  « » S70A L" 
fJCHAFL  * 5 

SK-tP  C Rjvbeti  ■**/ 


Skip  Un<L  txponz,  <?'  dpter 

t_  t>ecLAk6  - CcM  $ FlUfyCOM  0-) 
fo  return  L-  Un%Ch  thru  pi rst 
comma  not/n  Quotes  or  parens 
or  L * Lcn$£h  Laiv&  tf  no  comma  • 

Bach  phase,  stored orsepordtc  buffer 
Lore,  by  3T6XT. 

STtvch'te*  indented  dc cording  tv 
teue/. 


VES 

srjfssrnore 

> > 

ldCL' 

F COMMA: 


CAII  F/K/PCOM  Cl) 
to  (nub  phrase,  tenn&j 
thru  comma- 


l&peAT* 


Puf  pnrdtxL  mtq  reMUA/&,f(£' 

OdttkiL  — 


j\es 

tom  ccyn^&ufj 


12J KJ  P&*  - l^j  K/t>e*  -v  I 
n/cmasl-i 


L6UEL-  CL€l/€+  SU€l/-^6®f  LMA£6»*j) 

S^lpar  o 

TVPg.PR£P/<.LAB^-g 


istore  phrase 
~7  (caw  e>re<  rCreM  uui) 


XX.LBKJj>: 


V&S,  finished 


a*AMh£€*C,P  N 

S -<i^> 


Moue.  uve  up 

(Uw£-  LAl) 

P€»fcTfe  U*fcW6  BtAMKS 


■ 194 


el$£  C coiled  /*/  PUSH  Poll) 
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IF  Procedure. 


Ci'CF- 


TVRr  Obf*  «>e  - C T <.L. 

^ --,  c v^O  - c. 


: &'< tc'r // / /piV?  ^7'U/a  //sr, 

(2  l£L'£l  : 

zlao*  / ’3  : 

CAL—  T\  ~iri  i>cl t 1 F ' 

LEI  '£.LifrA.-i)BA)4lL£l'£L-f  j 


-x  inv  ( i fVt-,jrr>0  4 ,•  .vliv-uT^ 
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ICS- Six  & 


Sk.i  ^ tc£»r«“  + 

e«-cW  -C©  <"“ftro~Y 
L.«  v<{  t * r»LSV  T jjttirt. 
©r  CUS/C  u . 


levs t-ruv 

^tfVxo 


D^lru'ikiw  *-<Vi’ 
lr*i»  c ftdff . 


SKIP  W 

Si.  r A 


fitly 

\Jt 


CL— M STPYT  Ve~W 
LIVE"  U to*«f*r 


5 


rii  • j. 


cHtr 
X©*.. 
,-f  etSFrt) 


(v\0  VcLP  ( THe©-er>) 


\ * <■  1^* 
PLtT^TT 


(JUpicJtv 

(C^aryT-Ccaf^r- 
th  coo  )A 


"ft*  3cT.-  I lC*COo^ 

/xNPet  (tct)  - 

. LX  r<  TtTH>^ 


T ! 


Xit  PXc  £ s 


Cufe*  t-i  |>LBOrT  aWev  CUT^T 

% y*%cV£  °*Y*  X”  ev^ali  V\  V <vc\  V7^W'^'V  l'*«Si 

iwwi\-  «~w  ** 

«'«  '■•"■  f ^V"~  - 

\ I ^ -ft  . Coa-fTT.  ■*  <* 

i;Xv:  *•-<*'• 

STcCtev-e-^  "tc  ^ Lw-Ut^fi-. 

w.tw«  urc»j>Ef  d'-3b 


■ l 

C leeTu-tft^  J 


Ok/xu-B 


For-  '<sri  C V *N  DJ T X fo » ' 

$X.frNAV-  <w4.  ^.6V6-<Z.T 

do-cVs  bU^fc  Sf>«-t<a 

U««,^iV»wi  \>^  Uv‘e\  rTW 

aetv  ' e>ivi ' *t.  ;«cUi.^o 

cktc^v*  v w Wen  Ofs/^t^Gr  J1  ***  ?,  ' 

A X ' , % C^tU^  v**c- 

^-tw«  -w.*«**^  **"  h 

ti  ‘lvVNyW ^ •**'  ^ t0n*t’f°  4 

i *\^  t tJJ>  i 
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201 


vetSi> 


Frorr\ 

■pLeDlT 


Fioccs&es  &c$£meiit  idhtcfi  work, 
ttrmmahcn  # PR.OC,  uo  &eauu  blocks . 
Corrects  push doiur  List,  one!  nesting 
Lew  I-  IT  '€AJt>LA&  Ct  )s  popped  up' 
until  lab  is  rmkiied.ifricf,  first  f%6mt 
t>o.  or  PPoc  uiune/  is  popped  up.  *v/Lh  d*  / 
mcJudrd'Bmky'  ' 

Cnpac^^os^ob  endup  nr  OO  CdU&T/'cAd 
— bihct-f  ueiere. dotted  'uh<L  follows  £/Ul>. 


C&H  *St ex  h> 
sf rye  u/ve 


L-VAR-  PlAi  K.'  i 
6,0  TO  ^Tg&A. 


-^(figTUEW  ) 


K/A  HAVIT} 

WO  - / FLAG  = I 


FLAI/Oj^ 

>tAX  I 

e/wrP./ 


CAL-u  RiPtfl^TOUL  I 


ik 

(call  PqPOP (f5TACtcQ^ 


VCCCpLoagMC-K^ 
“ R>fe.uAe> 


f 

i> 

\ 

£_ 

CLeveL.* 
LCWCL.  CF 

CLft/ 

^STACIC.'S) 

>i  mdcO  * 

et--H 

^ 

< 

(fegTURN/  ) 


V 


202 


~ 


. 


Ju: 


— 


'pOPt  r Suhrou  1 1 * ) fc- 

I 

! 

i 



flag 

C ? A I L Vvt'L  iJ  O'  1 f ^ 


— 


— ” " 


pcPaP 


-y  ' ^ l*  ^ * 

rt4u«U^  ( » si.  * 0<?<-  r*  ,cv  * 

C L£V  C u »f  ^cA  o-  - 


P*p.f. 

Pprvl, 


204 


pa-S  Lrt^L)y 


xf  flac-si  c.cev'tu  xj 

XV^CfCc  <*1  6"  'V1  •? i>  . PaiitteH 
/}U_<jrCAT«r,S  NjT^  are-li«<^t' 

srvtcKi,  srrti^*lsMtw 
^ ofe^ATreiv  , tA tJtr<-(>) , t-«rv<r«-)( 
?a.^rtjNft  (^(tevx^ai  vAcc'C-i' 

3 Gr-SAJ  N'  , 


i 

I 

l 


f 


\ 


205 


— 


— 


— 


— 


— 


— 


'PushPul 


Checks  on  (orfcGeyrf-  csfcit vo 
of.  xf.v.  etse  ?Jructcre<e 
and  Ufxidtes  pLiahClownLiSte- 
\f  necessary. 


SM  A (LQr 


Level  o .ft «vo 

v^o_>ro.'>~  i*  I ^ 'tL« 

JLec|tr»+,  e n S+  . ( ? ^OIT)  0.S  I . 

JMAi tG-Stf  <w-k  }E^.<vtA*G- 


r 
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APPENDIX  C 


CONCEPTUAL  GROUPINGS  PROGRAM  FOR  PL/1  (GP-P) 


5.  SOURCE  PL/1  PROGRAM  OF  (GP-P) 
UNGROUPED 


1J 


RUN  NO.  7231 


DATE  C9/02/74 


TIME  123a 


LISTING  OF  MC 


DESCRIPTION  PL/ I FORMATTER 

ACOED  TO  MASTER  C7/19/7A 

LAST  OAT E_COP IED  NCME 

LAST  UPCATEO  " ' KCNE 

PASSWORO 

PROGRAMMER 
TYPE  PARAMETER 
EXEC  PARAMETER 
CPTION  PARAMETER 
JOBNAME 

SLAMP  PARAMETER 


PWGC 

BRYAN 

COPPCAT 

PLICPT 

NGSYM.NOXREF.NOLiSTX 

NONE 

NO 


PLEDITJ  PROCEDURE  CPT IONS! MAIN ) : 

OCL  TLINE  VAR  CONTROLLED; 

OCL  STATEHENT_SIZE  FIXED  DECIMALI7I ; 

DCL  MAX.LINES  FIXED  DECIMAL! 71 S 
OCL  SECNO  CHARI  81; 

DCL  CONT.CHAR  CHARI 1): 

DECLARE  SYSPRINT  PRINT  ENVI  MEDIUM!  SYSLST . I<»OJ  I F RECSI2EI133I 
BUFFERS! 21 I ; 

OECLARE  CCIN  STREAM  INPUT  ENVI MEDIUMISYSU0A.25A0I  F RECSIZE! BOI ) ; 
/*  PART  1 INITIALIZATION  */ 

/*  BUFFER  STORAGE  */ 

/*  LINOEX  IS  POINTER  TABLE  TO  BUFFER  */ 
fo  /*  BUFFER  IS  6 ARRAYS.  EACH  DIMENSIONED  50  */ 

/*' LABEL  PREFIXTfL'Ov  MAX  OF  5 TO  « ST.  */ 

° DCL  LIN0EXI20)  FIXEO  BINI15.0I  InITIIZOIO). 

text!*)  Chari 120)  var  contkjlled, 

PREFIX!*,*)  Char (311  var  controlled. 

LABEL!*.*)  CHAR! 21)  VAR  CONTROLLED, 

TYPE!*)  CHAR ( 4)  VAP  CONTROuLEO. 

LEVEE  r*  nBEC"  FI  xEDm'XONTaULLcD, 

SEJ*!*)  CHAR! 3)  CONTROLLED. 

SKIP!*)  BIN  FIXED  CONTROLLED: 

/*  COUNT  =' NUMBER  OF  CURRENT  STATEMENT , 

R INDEX  IS  POINTER  TO  CURRENT  BUFFER 

.line  */ 

OCL(CCUNT.RINDEX)  BIN  F 1 XEO ( 1 5 . 0) J N I T ( 0 ) : 

/*  MARGIN  TABLE  ANS  PARAMETERS  FOR  PRINTING 
ANO  COMPUTING  MARGINS  */ 

OCL  MARGIN (0:15)  BIN  FIXED! 15 , J)  INI  Til), 

! OELMARG  INIT(2),  I MARGIN  INIT(9I. 

NCOL  iNlT(eO))  BIN  FIXED(15.0) . 

PAGENO  DEC  FlXEO!  f,OT  INTTU ) : 

/*  PUSHDOWN  LISTS  : STACK1  = OPERATION. 

STACK2  HAS  LABEL! S),  STACK3  = LEVEL  */ 

OCL  '(STACK!  CHAR!  5)  VAR,  “ 

STACK2 ( 5 ) CHAR ( 31 ) VAR, 

STACK3  DEC  FIXED(2))  CONTROLLED: 

/*  80-C0L  RECORDS  ARE  READ.  1 aT  A TIME,  INTO 


* Y 


i 


— 


VLASICH 


00000010 
00000011 
00000012 
00000013 
0000001 A 
00000015 
00000016 
00000017 
00000018 
00000020 
00000030 
00000040 
00000050 
00000060 
00000070 
00000080 
00000081 
00000082 
00000083 
00000084 
00000085 
00000086 
00000140 
00000150 
00000160 
00000170 
00000180 
00000190 
00000200 
00000210 
00000220 
00000230 
00000240 
00000250 
00000260 
00000273 
00000280 
00000290 


09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 


09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 


09/02/74 
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TIME  123b 


LISTING  CF  MODULE  VLASICH 
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NCARC.  EACH  STATEMENT « AS  IT  IS  SEPARATED 
FROM  NCARD.  IS  STORED  IN  LINE  FUR  ANALYSIS. 
TEMLINE  IS  WORKING  STRING  STORAGE  */ 


DCL  NCARO  VAR  CONTROLLED. 

LINE  VAR  CONTROLLED. 

TEMLINE  VAR  CONTROL LED 5 

/*  MISC.  VARIABLES  : FLAGS.  ETC.  */ 

DCL  C COMFLG.THFL ) FIXED  BIN!15.0)  1NITI0I. 
CMNC  CHAR  C 10  I VAR. 


ho 

]=T 


(NV1.NV2.NST. NEND.THISN.LASTN.Pri 
BIN  FIXED! 15.01  * 

XL  cflag.finis.levf.onflag.rflagi 

BlT ( 1 ) IN  IT ( • 0*  B ) ; ~ 

/*  CLEVEL  IS  CURRENT  LEVEL.  PLe / d 

SAVED  PRECEDING  LEVEL  USED  IN  SOME  

ELSE  STATEMENTS  */ 

XL  (CLEVEL. PLEVI  DEC  FIXEDI2*  INITIO); 
/♦BINARY  CONSTANTS^  */ 

DCL  (ZB  INIT(O).  ONEB  INI  TUI. 

TWOB  INITC2I  I BIN  FIXEDU5.0): 

/*  LCCK  FCR  CG  WHEN  COUNT  * BJFCb!.*20). 

TESTCG  = NUMBER  DEFINING’ A Cb  ( • *HAtFCG. 
WHICH  IS  BUFCG/2)  */ 

XL  (BUFCG  INI T( 20)  .HALFCG. 

fESTCG  I N I T ( 7 ) j BIN  FlXEDC15.ui  5 
/*  CHCODE  TABLE  SEPARATES  SKIPCODE  INTO  FORE 
AND  AFT  COMPONENTS  */ 

XL  CHCODE ( 0:9.2)  BIN  F I XED (1 5 • 01 

IN  I T ( 0.0*  1.0.  1.3.  0.3.  0.4.  0.5. 

6.0.  6.4*  8.0.  8.41 • 

/♦  statement  types  */ 

XL  LTYPE(7I  CHARI4I  VAR  INIT 

(•AST*.  •I0*.  'CAL'.  •CTRL*.  'STOR*. 

•CN^.“C0M«~TT 

/♦  BREAK  CHARATERS  AND  NULL  ARRAY  */ 

XL  BLANK  CHAR(l)  INIT(*  •); 
xr  bRKCEI  CHAR! 2)  VAR  IN7T 

•.».  •(•.  • J • . •/*•.  •*/•.  1 

XL  „MTLAB(5>  CHAR  ( 2 I VAR  INIT!I5I"I_S 
/♦  INPUT  IS  SYSTEM  FILE.  CAROS. BOCJL.  " 
PROVIDE  FOR  END  OF  FILE  */ 

ON  ENDFILE  (SYSINI 
BEGIN  ; 

FINIS  = ,1*B: 

GC  TO  ENDRD; 

end: 

/♦  READ  IN  LINESIZEC80  OR  120)  FOR  OUTPUT. 
MARGIN  PARAMETERS  */ 


) ; 


ON  ENDFILE(CCIN)  BEGIN: 

PUT  EDITC'NOT  ENOUGH  CONTROL  INFORMATION  SUPPLIED  ( S YS004) • * I C A I • 
PUT  EDIT! * IT  EM  Is  LENGTH  OF  PRINTLINE:  SUGGESTED  120 • l( S KI P( 1 ) . A) : 
POT  ECITT^TTEH  "2 : ^EGrNNTN^"KrRCTM;”SUG^ESTEO  9 rr(3Rl  PTTI .A) ; 

PUT  ECIT ( • ITEM  3:  MARGIN  STEP  SIZE:  SUGGEST  5 ■ I (SKIP! 1 ) * A) ; . 


00000333 

00000310 

00000320 

00000330 

09/02/74 

03000331 

09/02/74 

00000332 

09/02/74 

00000363 

00000370 

00000380 

00000390 

00000400 

000C0410 

00000420 

000CC430 

00000440 

00000450 

00000460 

00000470 

00000483 

00000490 

00000500 

00000510 

00000520 

00000530 

00000545 

00000550 

00000560 

00000575 

00000580 

00000590 

00000600 

00000610 

00000620 

00000630 

00000640 

00000650 

03000660 

00000670 

00000680 

00000690 

00000700 

00000713 

00000720 

00000730 

00000740 

00000750 

OOOCC760 

00000770 

00000780 

09/02/74 

00000781 

09/02/74 

00000782 

09/02/74 

00000783 

09/02/74 

00000784 

09/02/74 
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the 

the 

MAX 


NUMBER  20'HSKIPtll.Ai  : 

NUMBER  7'I(SKIP(U.A)  : 

# CHARACTERS  PER  PL/I  STATEMENT; 


PUT  FCIT1 'ITEM 
PUT  EDITCITEM 
PUT  ECIT ( • I TEM 
(SKIP(l).A) ; 

PUT  EDIT! ’ITEM  7:  MAX  # EDITEC  LINES  PER  PL/I  STATEMENT; 

•50*  MSKIP(l).A); 

PUT  EDIT ( ‘PROGRAM  TERM  INATED.  • (( SKI  Pill . A) ; 

SIGNAL  ERROR: 

END; 

OPEN  FILE(CCIN) .FILE(SYSIN) : 

GET  FILE(CCIN)  L I ST( NCOL. I MARGI N. OELMARG) ; 

/*  DEFINE  OPTIONS  FOR  OUTPUT  (S/SPRINT)  */ 
FlLEISVSPRINTJ  ; 

ACTION  AT  PAGE  END  */ 

ENCPAGE  (SYSPRINTI 
BEGIN; 

PAGENO  * PAGENOU: 

PUT  FILE  (SYSPRINT)  PAGE  EDIT 

(•PAGE  •.  PAGENO)  (COUNCOL-3)  .A.FC  3)  ) ! 
eno; 

TITLE  FIRST  PAGE  */ 

PUT  FlLE( SYSPRINTI  EOfTPiUSTCT  TBITE’D  "By  FLEDITt» 
•PA»»E  ‘.PAGENO) 


00000785 

00300786 
SUGGESTED  800‘ 100000787 

00000788 

SUGGESTED  *1100000789 


OPEN 

/* 

ON 


/* 


fO 


*/ 


HO 


( SKIP (2  >.COL< 10) .A,C0L(HlJL-8I ,A,F(3) I 
PUT  SK IP( 2 ) ; 

/*  INITIALIZE  PUSHDOWN  STACK 
ALLOCATE  STACK1  INIT('TOP'), 

STACK2I5)  INITKS)"). 

STACK3  INIT(C): 

/*  ADJUST  LINELENGTH  FOR  LEVEL  PRINTOUT  */ 


TP 


ncol  * so  Then 

NCCL  = 725 
ELSE  NCOL  = 116; 

/«  PARAMETERS  FOR  CG  SEARCH  *7 
GET  FILEICCINI  L 1ST ( BUFCG. TESTCG1 ; 

HALFCG  * BUFCG/TwOB: 

it  test  eg  > halfcg  then 

DC: 

PUT  SKIP  LISTCTESCG  MJST  BE  < HALF  EUFCG'li 


*/ 


stcp: 

END: 

/*  GET  STATEMENT  SIZE 

"Get  FILEICCINI  LISt(  ST ATEMENTIT5i'Zfc.MAX_L INES  f : 
ALLOCATE  TEXT ( MAX_L INES) . PREF I Xi MAX.LI NES . 5 > . 
LABELINAX.LINESf 51  , TYPE (MAX_LINcSI , 


SEO*( MAX. L INES) , 
LEVEL (MAX_LINES) . 
TEXT*  ' • : 

TREFIinn » • 


SKIPIMAX, LINES) 


LABEL*'  • : 
TYPE**'  : 
LEVEL* 


SKIP 


•o: 

*0: 


PAGE  .3 


09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 


0000079 0 

09/02/74 

00000791 

09/02/74 

00000792 

09/02/74 

00000793 

09/02/74 

00000794 

09/02/74 

00000795 

09/02/7* 

00000796 

00000800 

09/02/74 

00000820 

00000830 

00000840 

00000850 

00000860 

00000870 

00000880 

000C0890 

O0O 00900 

09/02/74 

00000901 

09/02/74 

00000920 

00000930 

00000940 

00000950 

00000960 

00000970 

00000980 

0OOOO990 

00001000 

00001010 

00001020 

00001030 

09/02/74 

00001040 

00001050 

00001060 

00001070 

09/02/74 

00001090 

00001100 

00001101 

09/02/74 

00001102 

09/02/74 

00001103 

09/02/74 

00001104 

09/02/74 

00001105 

09/02/74 

00001106 

09/02/74 

00001107 

09/02/74 

0 0001103 

09/02/74 

00001109 

09/02/74 

00001110 

09/02/74 

00001111 

09/02/74 

00001112 

09/02/74 
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t 


LISTING  OF 


RUN  NO.  7231 


ALLOCATE  rilN^  CHAR(STiTTEMENT.SI^c)  INITCM; 

ALLOCATE  NC ARC  CHAR C ST ATEMENT_SI ZE I INITC 1 • I J 
ALLOCATE  LINE  CHAR  { STATEMENTS  IZc  i lrtlT<va)S 

Allocate  temline  chari  statehent^suei  initi  ; 

/♦  CREATE  MARGIN  TABLE  ♦/ 

CALL  SMARG: 

/♦  PART  11  ♦ / 

/♦  HERE  ME  START  EDITING.  1 STATEMENT  AT  A TIME  ♦/ 
/♦  UPDATE  POINTERS  AND  INDEX  ♦ / 

GO:  COUNT  * CGUNT+ONEB; 

RINDEX  * ADDPTRCRINDEXI : 

LI NDEX( COUNT ) * RINDEX; 

—?+  GET  1ST*  S T ORE ~C0  NOT  T I ON  PRFix  AND/OR  LABEL  ♦ / 
/♦  IF  ECF.  EMPTY  BUFFER  AND  ENJ  ♦ / 

CALL  READ; 

/♦  COME  HERE  ON  EOF  ♦ / 

ENDRD:  IF  IFINISI  THEN 

IF  I-.RFLAG)  THEN 

bo'; 

COUNT  = COUNT-ONEB; 

RINDEX  ^ SLBPTR ( RI NJc X ) ; 

GO  TO  TFCG: 

END: 

ELSF 
DO : 

PUT  SKIP  LIST! •♦♦MISSING  CARD(SI**al; 
ro  GO  TO  ENDPROG; 

Xrt  ENG: 

/♦  NOT  ECF.  ANALYSE  STATEMENT  FOR  TYPE. 

GO  TO  TYPE  ROUTINES.  UPQATc 
PLSFCOmN  LIST.  ASSIGN  LEVEL  AND 
SKIPC0DE.  STORE  IN  BUFFER  ♦/ 

/♦  IS  IT  COMMENT  ? ♦/ 

irTCMFLG  = ONEB  THEN 
DO: 

CALL  comment: 

GO  TO  P 3: 

END: 

/♦  NO.  LPCATE  STACKS  ♦ / 

CALL  PUSH PUL: 

/♦  NULL  ST.  ? ♦/ 

IF  LENGTMLINEI  = ONEB  THEN 
GO  TO  C 8: 

/♦  THFL  IS  CLUE  TO  TYPE  */ 

/♦  COMPLETED  1 ELSE  • ? ♦/ 

IF  THFL  = TWOB  THEN 
GO  TO  P3 : 

/♦  FOR  THFL  = 0 OR  3 ♦/ 

/♦  IS  IT  PREPROCESSOR  STATEMENT  ♦/ 

IF  SUBSTR(LlNEtl.l)=,%1  THEN  DJ: 

C OUNT -COUNT- 1 : 

CD  "TO"TESTFN  : 

END; 
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00001113 
00001114 
000011 15 
00001116 
00001117 
00001120 
00001130 
00001140 
00001150 
00001160 
00001170 
00001180 
000  Cl 190 
00001200 
00001210 
00001220 
00001230 
00001240 
00001250 
00001260 
00001270 
00001280 
00001290 
00001300 
00001310 
00001320 
00001330 
00001340 
00001350 
000C1360 
OOOC1370 
00001380 
00001390 
00001400 
00001410 
00001420 
00001430 
00001440 
00001450 
00001460 
00001470 
000C1480 
00001490 
00001500 
00001510 
00001520 
00001530 
00001570 
0 0001571 
00001572 
00001573 
0 0001574 
00001575 


09/02/74 

09/02/74 

09/02/74 

09/02/74 


09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 
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r 

/♦  iS~IT  AM  ~MF»  ? */ 

Cl:  CMND  * SLBSTRCLlNE.l *31 ; 

IF  (CMNO  * • I F • I I (CMND  = • IF4 • I I 

( CMN  C * • I F • • * I THEN 
CALL  IF5 

_/*  JS  IT  OC*  PROC*  BEGIN  OR  EN T <Y  ? */ 

C2:  CMND  * SUBSTR ( LINE* 1 *6) ; 

IFCCMNO  * • ENTRY  • I I (CMND  a #BcGIN  Ml 
CCMNC  » #ENTRY: • ) I (CMND  * • dEGi M5  • I THEN 

GO  TO  yesbl: 

CMND  a SUBSTR (LINE*1*3); 

IF  C CMND  * •DO:* II (CMND  a *00  • I THEN 
GO  TO  YES3L; 

CMND  » $UBSTR(LINE.1*5I 5 

IF  CCMNQ  a •PRQC;« ll (CMND  a »PkJC  • I I 

(CMND  * • PROC ( • I THEN 
GO  TO  YESBL; 

CMND  a SUBSTR! LINE* 1 • 10)  ; 

IF  CCWD  ^ •PROCEDURE  •!  & ( CMND  • PROCEDURE ;•  I 

L (CMND  *■•=  • PROCEDURE!  • I THEN 

GO  TO  CC2 

/*  I T IS  A BLOCK  COMMAND  */ 

. YESBL JCALL  BLOCKCCMND); 

GO  TO  P3; 

I /*  TRY  FOR  •END1  ♦/ 

CC2:  CM NO  » SUBSTR ( LINE * 1 *41 ; 

IFCCMNO  a «END  • II  (CMND  = <ENO;»  l_  THEN 

DO; 

CALL  PEND; 

GO  TO  P3: 

end; 

/*  IS  IT  A CONTROL  STATEMENT  ? */ 

C4S  CMND  a SUBSTR ( L IN£ * 1 ♦ 51 : 

IFTCMND  « * CALL  • I THEN 

do; 

CALL  CTRLC; 

GO  TO  P3 ; 

END; 

IF (CMND  » •GOTO  • I THEN 

GO  TO  C41 ; 

IFCCMNO  = ‘WAIT  • I I C CMND  a •^AIT;lll 
CCMNC  = • STOP  •IICCMNO  * «^TOP;MI 
C CMND  a EXIT  •IICCMNO  = •tXlT;r>  THcN 
GO  TO  C44; 

CMND  « SUBSTR! LINE* 1 *6l : 

IFCCMNO  = •DELAY  '|TC CMND  a • DELAY'; • I THEN 
GO  TO  C445 

IF  ( CMND  = *G0  TO  •!  THEN 
C41 : DO: 

CALL  CTRLG; 

GO  TO  P3; 

ENO; 

CMND  * SUBSTR (LINE* 1*7); 


* 


i 
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00001580 

00001590 

00001600 


. r ■ ,y 


6600TS50 

00001890 

00001900 

...  • 

* vJV 

00001910 

00001920 

00001930 

dswmcr 

00001950 

00001960 

<mm  V M 

00001980 
00001990 
0W02CW 
00002010 
00002020 
60o02S30 
00002040 
00002050 
Odd 02660 
00002070 
00002080 
00062090 
00002100 
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• IF  ICMNO^  • RETURN'  •NICMND  = 'RcTURN:'!  THEN 
C44:  do: 

CALL  CTRL05 
GO  TO  P3: 

end: 

/ * NOT  CCNTROL  ST  ♦/ 

/*  IS  IT  10  ? */ 

C5:  CMND  » SUBSTR ( L I NE . 1 .41 : 

IFICMNO  «_^GET_'  I I (CMND  » 'PUT  • I THEN 
GO  TO  C55: 

CMND  * SUBSTR(LINE,1.5»: 

IFICMNO  * 'OPEN  'll! CMND  * 'READ  *1  THEN 
GO  TO  C$5: 

CMND  = SUBSTRILINE.1.6! : 

IF | CMND  = 'CLOSE  ' I I I CMND  * 'WRITE  • I THEN 
GO  TO  C55: 

CMND  * SUBSTR I LINE* 1*71 1 
IFICMND  - 'DELETE  » > IICHWO  « 'LJCATE  'll 
tCMND  * 'FORMAT  • fl  I CMND  * 'FORMAT  Cl 
THEN 

GO  TO  C55t 

CMND  - SUBSTR! LINE* l.eTT- 
IFICMNO  * 'REWRITE  • I I (CMND  * 'DISPLAV  •) 

THEJN 

C55  s DO: 

CALL  IQSUB: 

ISO  GC  TO  P3: 

^ eno; 

/*  IS  IT  DECLARATION  ? */ 

C6 : IF  € SUBSTR(LINEfl.4>  = 9DCL  Ml 

'(SU8STR<LINE.1.8)  * 9 DEF AJL  T Ml 
(SUBSTRILINE.1.8)  * • DECLARE  Ml 
CSUeSTR(LINE.It9)  9 ALLOCATE  •)  THEN 
DO; 

CALL  DECLARE: 

GO  TO  P3: 

-tNOr 

IF(SUBSTRUINE.1.5)  = 9 FREE  91  THEN 
GO  TO  C8; 

/♦IS  IT  CN.  SIGNAL.  REVERT  ? */ 

C7 : IFISliBSTR(LlNE.1.3l  = 90N  Ml 

( SLBSTRiLlNEtl.T)  * 9 SIGNAL  Ml 
C SUBSfRCLINE.1.7)  * 9 RE VERT  *1  THEN 

do; 

CALL  onsub; 

GO  TO  P3f 

END; 

/*  NCNE  OF  PRECEDING.  CLASS  IT  ASSIGNMENT  ♦ / 

C8 : CALL  ASSIGN: 

/*  PART  III  */ 

/*  RETURNED  FROM  TYPE  SUBS.  NO*  CHECK 

pQft  miTpQT-"CG , FTC. ~ TETURN" TO  9 GO 9 

IF  INPUT  REMAINS.  OR  TO  END  PkOGRAM 


VLASICH 


PAGE 


000021 10 
00002120 
0C0G2130 
00002140 
000U2150 
00002160 
00002170 
00002180 
00002190 
00002200 
00002210 
00002220 
000C2230 
00002240 
000C2250 
00002260 
00002270 
000C2280 
00002290 
00002300 
OOC02310 
000023 20 
00002330 
00002340 
00002350 
00002360 
00002370 
00002380 
00002390 
00002400 
03002410 
U00C2420 
00002430 
00002440 
00002450 
00002460 
00002470 
00002480 
00002490 
00002500 
000C2510 
00002520 
00002530 
00002540 
00002550 
00002560 
00002570 
00002580 
00002590 
00002600 
00002610 
00002620 
00002630 
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DATE  C9/02/7A 


TIME  !23o 


LISTING  OF  MOi 


RUN  NC.  7231 


IF  FINISHED.  */ 

P3:  THFL  = ZH ; 

_ /*  PCINTER  TO  FIRST  BUFFER  L INC  OF 

CURRENT  STATEMENT  */ 

THISN  = L INDEXICOUNT  I ; 

__  NVl  * SKIP! THISN I: 

/*  IF  THIS  IS  VERT  FIRST  ST.  DU  AN V 
PRE-SKIP  */ 

IF (COUNT  > 11  THEN 

GC  TC  MORN1 : 

NV2  * CHCCOE( NVl.ONEB) : 

IF  NV2  * IA  THEN 

GC  TO  TESTFN5 

IFINV2  = CNEB  1 1 1 NV2  = 6 I I (NV2  = al  THEN 

CALL  OUTFST (NV2 J • 

/*  SUBTRACT  PRE-SKIP  FROM  CODE  •/ 

SK  IP(  ThISNI  > CHCOOEINVl  . TWJdl  : 

GO  TC  testfn: 

/*  NOT  LINE  I;  PTR  TO  LAST  Lilt  FO  PRECEDING  ST  */ 
MOPN1 :LASTN  = SLBPTRC  THISN  • • 

NV 2 = SKI  PI  LA  STNI  : 

/*  RULE  1 : FLAG  OUTPUT  IF  CHANGE  IN  LEVEL  */ 
RULEUIFILEVELI  THISNI  = LE VEL( LASTNI J THEN 

_ LEVF  * 

ELSE 

LEVF  = »1*B: 

fc*  /*  RULE2  : EXAMINE  CURRENT  ST.  FUR  PRESKIP. 

CT>  IF  FOUND*.  AO“d“  To  PREV.  ST.  SUBTRACT  HERE  */ 

RULE2* IFINVl  = CNEB  I I (NV1  * TWOBI  THEN 
I FINV2  = AIIINV2  = 51  THEN 
SK  IP  I LA  STNI  =5J 
ELSE 

SK IF ( LASTNI  = 3: 

ELSE 

I F(NVl  = 6IIINV1  * 71  THEN 
SKIP! LASTNI  = 55 
ELSE 

IFINVl  = 3IJINV1  = 91  THEN 

IFINV2  » ZBI  THEN  

SKIPILASTNI  * A; 

ELSE 

IFINV2  = 31  THEN 
SKIPILASTNI  = 55 

SKIPITHISNI  = CHCODEISKIPITHISHI  .TROdl  ; 

/*  RULE3  D IMPLEMENT  SKIPS  F JK  PRECEDING  ST  */ 

"7*  ALSO  OUTPUT  IF  LEVEL  CHANGE 
(RULE  1 1 */ 

RULE3:NV2  « SKIPILASTNI; 

IF  ("L  EVF  1 1 (NV2  -.=  ZB f THEN 
DO; 

CALL  OUTPUT  I COLNT-ONEB I : 

CALL  MO VUPI COUNT— ONE8 I ; 

GO  TO  TESTFN; 


* 
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03002640 
JG0C2650 
00002663 
00002673 
00002680 
000C2690 
00002700 
00002713 
00002720 
00002730 
00002740 
00002750 
00002760 
00002770 
000C2780 
000C2790 
00002800 
00002810 
00C02820 
0 00C2830 
000G2840 
00002850 
000C2860 
00002870 
00002880 
00002890 
000C2900 
00002910 
00002920 
00002930 
00002940 
00002950 
03002963 
00002970 
00002980 
00002990 
00003000 
00003010 
00003020 
00003030 
00003040 
03003050 
00003060 
00003070 
00033080 
30003090 
00003100 
00003110 
303C3120 
00003130 
00003140 
00003150 
00003160 


i 
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PUN  NO.  7231  DATE  £5/02/74  TIME  123d  LISTING  CF 

n 

' ~ encT 

/*  NO  OLTPUT  YET.  LOCK  FOR  CGIF 
BUFFER  * BUFCG  OR  IF  (EOF  ANU 
BUFFER  > HALFCG) • */ 

IFCG:  IF  (CCUNT  = BUFCG)  I ((COUNT  >*  HALFCG) 

£ FINIS)  THEN 

go  t o rllea; 

/*  NOT  FULL  ENOUGH.  READ  MORE  UNLESS 

NO  MORE  I NPUT_  _*/ 

TESTFNsIF(^FINIS)  THEN 
GO  TO  GO; 

/*  EMPTY  BUFFER  AT  END  */ 

OUTENO: CAnT'GUT  PUT  (COUNT)  ; 

GO  TO  ENOPRGG; 

/*  SEARCH  FOR  CG  ~ */ 

RULE4; IF4FINIS)  THEN 

CALL  CGEND(NST.NENO) ; 

ELSE 

CALL  CGFINtH  NST .NEND) S 
/*  NOT  FOUND t OUTPUT  HALF  BUFFER 

(OR  ALL.  IF  END  OF  DATA)  */ 

' ifinst  * zb)  then  " 

IF(FINIS)  THEN 
GO  TO  outend; 

ELSE 

do; 

CALL  CUTPUT(HALFCG) : 

^4  CALL  MCVUP(HALFCG)  ; 

GO  TO  GO; 

END; 

^TffUffDCG.  OUTPUT ‘PRE-CG  LINES  */ 

IF(NST  = ONEB)  THEN 
GC  TO  cgout; 

PT  * SuBPtR( lInDE’x(NSTF)  ; 

SKIP(PT)  * 3; 

NST  * NST-QNEB; 

arcn^TPUT(NsT) : 

CALL  MOVUP(NST); 

/*  OUTPUT  CG  */ 

NEND  * NEND-NST; 

CGOUT:  IF (NEND  = COUNT)  THEN 

GC  TO  OUTGP; 

PT  * $L8PTR( LINDE X(NEND*ONEB) ) ; 

SK  IP(  PT  ) = 3: 

OUTGP:  CALL  OUTPUT (NEND ) ; 

CALL  MCVUP(NEND); 

GO  TO  testfn; 

/*  ALL  INPUT  PROCESSED.  ALL  OUTPUT 
DONE.  TELL  IT.  * */~ 

ENDPROG:  PUT  PAGE  LIST  (•♦♦PLEDIT  FINE  SHED** • J 3 
/*  #*414 <***♦  PAGE  2C  ON  HANDWRITTEN  SHEETS  ********  */ 


VLASICH 


PAGE 


0G003I70 
000C3I80 
000C3190 
00 0032 DO 
00003210 
00003220 
00003230 
00003240 
0000325 0 
00003260 
00003270 
00003280 
00003290 
00003300 
00003310 
00003320 
00003330 
00003340 
00003350 
00003360 
00003370 
00003330 
00003390 
00003400 
00003410 
00003420 
00003430 
00003440 
00003450 
00003460 
00003470 
00003480 
00003490 
00003500 
00003510 
000G3520 
00005530 
00003540 
000G3550 
00003560 
000C3570 
00003580 
00003590 
00003600 
00003610 
00003620 
00003630 
00003640 
00003650 
00003660 
00003680 
00003690 
00003700 


Moure  Brnmen  furi't. 


RUN  NO*  7231 

r ^ 


DATE  C9/02/74  TIME  123d 


LISTING  CF  MODULE  VLASICH 


* /*  SUBROLTINE  READ  GETS  INPUT  ANQ 
BEGINS  TO  PROCESS  STATEMENT  */ 

READ:  PROC; 

/*  GETSTAT  PUTS  STATEMENT  i?4T0  UNE  */ 

CALL  GETSTAT: 

/*  COMMENTS  ARE  NOT  PARSED  */ 

IF  (COMFLG  = ONEB)  THEN 
RETURN; 

/*  RLABEL  SEPARATES  LABEL!  S)  A.*0 
CONDITION  PREFIX! ESI  */ 

CALL  RLABEL5 

NO*  RETURN  IS  MADE  TO  PLEDiT  */ 

READ: 

ppoc: 

DCL  CL ABL ! 0 : 2 1 LABEL  InIT ! I Si TC. COMT f NQCOMT I . 
(NCUOT.NCOM)  dlT(i)  INIT(#0#BI. 

KCH  CHAR(l). 

KCC  CHAR! 21. 

KS  BIN  FI XEU! 15 • U I J 
CCMFLG  * l R; 

IF  MORE  TEXT  NEEOED.  READ  Ned  RcCOru)  ♦ / 

IF  INCARD  = THEN 

DO: 

RFLAG  * 'O'B: 

CALL  in: 

END  Gi: 

SUBRCUT I NE  IN  READS  SYSIN  ( SYSTEM  FILE)  ♦ / 

oo  IN:  ' PROCr* 

/♦  READ  C^RD  C0L2  - 72.  APPEND  TO  NCARO  */ 

/*  ON  ECF . FINIS  * 1 AND  RETURN  MADE  TO  ENORD  !IN  PLEDIT )*/ 
AGIN: 

GET  FILEISYSINI  EClT(CONT_cHAR.L INEI 
( A ! 1 ) * A ( 79 ) ) : 

IF  NCARD®1 1 THEN  SECNO  = SUBSTR(  LInE.72 ) ; 

LINE  * SUeSTR!LINE.1.71) : 

IF  CONT_ChAR=*$«  THEN  DO: 

CALL  OUTPUT! COUNT-ONEB) : 

CALL  MCVUP! COUNT-ONEBI ; 

PUT  EC!T!LlNE)!SKIP(l>.xm.A)  : 

GET  FILE(SYSIN)  E OTT  ! CON  t.  CHAR  * L fME ) 

! A ! 1 ) .A! 7911; 

LINE- SUBSTR ! L INE  * 1 .71) : 

DO  WHILEICONTjGHAR-.*1*1  I 5 

PUT  ED!T!LINE)!SKIP!1) . X ! 1 4 • A ) ; 

GET  FILEISYSINI  EDIT ! CQNT_UHAR .LINE) 

(All)  • AI79 ) ) ; 

LINE* SUBS TR(LINE.l. 71) : 

END; 

PUT  EOITILfNEK  SKlP(l)  • X!1  ).a)  : 

GO  TO  agin: 
end: 

if  l I ne= • • Then  go  to  agin; 

DO  1*71  TO  1 BY  -1  WHILEISUBSTRILINE.I .!)*•  ' I ; 


/* 

END 

GETSTAT: 


/* 


Gl: 


£2  /♦ 


00033713 
00003720 
00003730 
03003740 
OOC  0375 J 
00003760 
00003770 
00003780 
0Q0C3790 
00003800 
00003810 
00003820 
00003830 
GG003840 
00003850 
00003860 
00003870 
00003880 
00003890 
00003900 
00003910 
00003920 
00003930 
00003940 
00003950 
00003960 
30003970 
00003980 
000G3990 
00034C00 
00004010 
00004011 
00004012 
00004013 
00004030 
00004031 
00004032 
00004033 
00004034 
00004035 
00004036 
00004037 
00004038 
00004039 
00004043 
00004041 
00004042 
00004043 
00004044 
00034045 
00004046 
00004047 
00004048 


09/02/74 


09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 
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END; 

IF  I <7 1 THEN  1*14-1; 

LINE*SUBSTR( LINE. 1 .1 ) ; 

DO  1*1  TO  71  mHILEI SUB STRI LINE .1.1)**  •!; 

END; 

IF  I>1  THEN  1*1-1; 

L I NE *SU BS  TRTlTN E • 1 1 ; 

I*LFNGTH(NCARD)  4-LENGTHILINE)  ; 

IF  I>STATEMENT_SIZE  THEN  00; 

PUT  EDIT! •STATEMENT  SIZE  EXCEEDED.  • M PAGE*  A I ; 
PUT  ED  IT  ( 1 NCARD:  1 «NCARDM  SKIP!  11*2  A); 

PUT  EO ITI • LINE:  1 «LINEI ISKIPtl) *2  AJ ; 

sfop; 


END; 


NCARO  * NCARD  I \ UNE; 


Cl! 


END  in; 

/*  BRANCH  FOR  TEST! COMFLG 
GO  TO  CLA8LIC0MFLGI : 


01 t COMMENT! il.  NO (21  */ 


*/ 


ro 

D 


/*  DELETE  LEAOING  BLANKS 
/*  IS  IT  COMMENT  ? */ 

1SITC:  NCARD  - SUBSTRINCARO.VERIFylNCARD.BLANKlI 5 

TP  InDE X( NC ARD . BSK (6T)  = 1 ThEN 

co: 

CCMFLG  * ONEB: 

GO  TO  COMT: 

END: 

/*  STATEMENT  IS  NOT  CCMMENT • 44LL  END  IN 
SEMICOLON  (NOT  IN  JJOTESTR 
COMMENTI  */ 

CCMFLG  « TMOB: 

NOCOMT:  DC  KS  * 1 TO  LENGTHINCAROI ; 

KCF*SUBSTR( NCARD. KS .1 ) 5 

IFIKCH  - BRKC3)  ) £ I-.NJU0T1  £ I-NCOM) 

Then' 

GO  TO  fbrk; 

IF  ( KCH  * BRKIll I THEN 
NQUOf  * -.NOOOT  : " 

ELSE  IF  KS-»=LENGTHINCARDI  THEN 

IF  ISUBSTR(NCARD.KS.2l*BRK<6»  I SJBSTRI NCARD ,KS ,2 ) »BRK(7 ) ) THEN 

NCOM  » -.NCOM; 

END  NOCOMT; 

/*  NO  ENDeREAK  FOUND.  GET  MORE  TEXT  */ 

TTURF:  R FLAG  = *l»B; 

CALL  IN: 

GC  TO  Cl: 

FOUND  ENUBREAk;  STORE"  STiTSTtfE'  */ 

FBRK:  LINE  * SUBSTRI NCARO. 1 .KS) ; 

/*  CLEAR  ST.  FORM  NCARD  */ 

NCARD  * SUBSTRI  NCARD, k5«-iT:‘ 
return: 

/*  COMMENT  ST..  FIND  END  */ 

~CUMT:  DO  kS  * 3 TO  LENGTH! NCARD)  - 1: 


KCC  - SUBSTRI NCARO. KS. 21  : 


00 304049 

09/02/74 

D000A050 

09/02/74 

00004051 

09/02/74 

00004052 

09/02/74 

00004053 

09/02/74 

00004054 

09/02/74 

00004055 

09/02/74 

00004054 

09/02/74 

00004057 

09/02/74 

00004058 

09/02/74 

00004059 

09/02/74 

00004060 

09/02/74 

00004061“ 

09/02/74 

00004062 

09/02/74 

00004063 

00004064 

00004065 

00004070 

00004080 

00004090 

00004100 

000041 ro 

00004120 

00004130 

0000414$“ 

00004150 

00004160 

000(5417(5 

00004180 

00004190 

♦ 

00004200“ 

00004210 

00004220 

000 04230 

00004240 

00004250 

00 004 260 

00004270 

09/02/74 

00004271 

09/02/74 

000 04 300 

00004310 

00004320 

00004330 

00004340 

00004350 

00004360 

00004370 

00004380 

00004390 

00004400 

00004410 

000C4420 

00004430 

Moore  luvneu  fo*m,  lot 


OATF  C9/J2/74 


TIME  123B 


LISTING  Cf 


RUN  NO.  7231 


IF  (KCC  = 8RKI  7M  THEN 

co; 

KS  * KS  ♦ i; 

GC  TO  fbrk; 

END  COMT; 

/*  NO  ENC  BREAK  FOUND  */ 

GC  TO  MORE; 

ENO  GETSTAT; 

/*  RL ABEL  IS  CALLED  BY  PLEDlTe  IF  AND 

ELSE  TO  SEPARATE'  ALL  PREFIXES  */ 

RLABEL:  prgc; 

DCL  ( KL  A , NLA8  INIT  (0)1  BIN  FIA6D(15,0), 

Kh  CHAR; 

/*  UP  TO  21  CHAR  IN  A PREFIX  ♦/ 

/*  FIND  ANY  CONDITION  j>REFIJC<£:>)  ♦/ 

CALL  SPREFX; 

SPREFX:  PROC: 

__  DCL  IIP.NP  INITIO))  BIN  FIXED  115,0); 

/*  SET  PREFIX  ARRAY  TO  NULL  */ 

PREFIXCPI NDEX,*)  = HTLAb; 

isitp:  np  = np+cneb; 

LINE  = SUBSTR CLINE, VERIFY (LINE, BLANK) i ; 


IF  SU3STR(LINE«1,1)**ZBRK(4I  THEM 

return: 

ro 

LPP: 

/*  FOUND  PREFIX  START,  LOOK  FJk  END  */ 

DO  IP  * 2 TO  LENGTh(LINE)  - i; 
IF  SUBSTRCLINE.IP.2)  ^*# ) S 1 

THEN 

o 

GO  TO  d'end; 

PREFIX! RINDEX,NP)  * SU  BSTRI L 1 NE  , 1 . 1 P 
LINE  = SUBSTRCLINc,IP  ♦ 2); 

♦ l) ; 

/*  REPEAT  EOR  ANOTHER  *f 

IF  NP  < 5 THEN 
GO  TO  ISITP; 

DEND: 

else  return; 
eno  lpp; 

/*  NO  END,  ERROR.  TRY  TO  GO  ON  */ 

put  Skip  list( •♦♦unbalanced  parens  in  prefix**1); 

IP  = INDEX! LINE  *BRK(8 ) ) ; 

IF  IP  = 0 THEN 

STOP: 

PREFIX! R1NDEX.NPI  z SU3STRI L I NE . I . 1 P ) 
LINE  = SUdSTR ( LINE « I P ♦ i): 

; 

IF  NP  < 5 THEN 

GO  TO  ISITP; 

END  SPREFX: 

/*  LOCK  f OR  LABEL (Si.  COLON  MUST  COME 

BEFORE  BLANK,  QUOTE  OR  LEFT  PAREN  */ 

LABELIRINOEX.*)  = HTLAB: 

RLl: 

/*~almays  delete  leading  blanks  "*/ 

LINE  = SCBSTRILINE.VERIFYUINE.BLANKII  : 
NLAB  z NLAB  ♦ I; 

RLP: 

00  KLA  = 1 TO  LENGTHILINE)  - l: 
Kh  z SUBSTRILI NEfKLAtl): 

• 

VLASICH 
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000C4440 
3303^453 
u 00  04463 
JOG 04470 
00004480 
00004493 
0000450 J 
00004510 
00004520 
00004530 
00004540 
00004550 
000045  SO 
00004570 
00004580 
00004590 
00004600 
00004610 
00004620 
00004630 
00004640 
00004650 
00004660 
000C4670 
00004680 
00004690 
000C4700 
00004710' 
00004720 
00004730 
00004740 
00034750 
000C4760 
00004770 
00004780 
00004790 
00004803 
00004820 
00004830 
00004343 
00004850 
000C4860 
00004870 
OOOC4E  83 
000C4890 
00004900 
00004910 
00004920 
000C4930 
033049*0 
00004950 
00004960 
00004970 


09702/74 


Moor  t Soimeit  ro'rT«t.  |n( 


n 


PUN  NO.  7231 


OATE  C9/02/74 


TIME  1238 


LISTING  CF  MODULE  VLASICH 


IF  (KH  i BRKC1U  I (KH  = BLANK)  I ( KH  = fiRKCAM 
THEN 

RETURN; 

IF  KH  * 8RK < 6 ) THEN 
CO; 

LAEEL(RINOEX.NL_AJ3)_~ 

SUBSTRCLINEt ltKLAJ : / 

LINE®  SUB$TR( LINE.KLA+1 ) ; 

IF  NLAB  < 5 THEN 
GO  TO  RLi; 

ENOS 

END  RLPS 
END  RLABEL ; 

/*  FUNCTICN  ADDPTR  AND  SUBPTR  ARE  CALLED 

TO  FIND  POINTER  TO  NEXT  (PRECEDING)  LINE 
IN  BUFFER*  BUFFER  STZE  IS  SET  TO  50  */ 

ADDPTR:  PRGC  (PTI  RETURNS  (BIN  F l XED( 15 .0 ) ) ; 

/*  INCREMENT  BUFFER  POINTER  */ 

DCLCPNEXT.Pfl  BIN  FrXED(15.3); 

PNEXT  * PT  ♦ ONES; 

IF  PNEXT  > MAX_LINES  THEN 
PNEXT  * ONES: 

RETURN  (PNEXT IS 
END  ADDPTR: 

SUBPTR s PRCCfPT ) RETURNS  (BIN  FI XEDC 1 3. J) I S 

/*  FINDS  POINTER  TO  PRECEDING  »UFFER  LINE  ♦/ 
po  XL  PT  BIN  FIOCEDC  15.0; 

£2  IF  (PT  - CNEB) > ZB  THEN  * 

RETURN  (PT  - CNEBI S 

ELSE 

RETURN! MAX«L INES ) S 
END  SUBPTR: 

/*  ASSIGNMENT  STATEMENTS  t FREE  ST. . ETC.  ♦ / 

ASSIGN:  PRCC*: 

/*  ARRIVES  HERE  BY  FALLING  THROUGH  ALL  OTHER 
CLASSIFICATION  TESTS  OR  AS  • FRcE • ST.  */ 

IF(TENGTh(LlNEK6)  1 (SUBSTRlLl  (E.1.5)  -=  •FREE  •) 

THEN 

TYPE(RINDEX1_*  LTYPE(l); 

ELSE 

TYPE ( RI NDEX)  *=  LTYPEC5); 

SKIP(RINCEX)  = 0; 

LEVELIR INDEX)  ® C LEVEL  : 

CALL  STEXTCLINE); 
end  ASSIGN; 

/*  PROCEDURE  FOR  BEGIN. DO*  ENT * Y. 

PROC  STATEMENTS  */ 

BLOCK:  PROC  (CMND): 

DCL  CMND  CHARI*)  VARYING; 

/*  ENTRY  SKIPS  LINE.  NO  LEVEL  cHAN^E  */ 

IF  (CMND  = 'ENTRY1)  THEN 
DO;  " 

SKI P( R INDEX)  = I; 


00004980 

00004990 

00005000 

00005010 

00005020 

0 0005030 

00005040 

00005050 

0 0005060 

000C5070 

00005080 

00005090 

00005100 

00005110 

00005120 

00005130 

00005140 

00005150 

JO  005160 

00005170 

00005180 

0O0C519O 

00005260 

00005270 

00005230 

000C5290 

00005300 

00005310' 

00005320 

00005330 

00005340 

00005350 

00005360 

00005370 

000C5380 

00005390 

00005400 

000C5410 

000C5420 

00005430 

00005440 

00005450 

000C5460 

000C5470 

00005480 

00005490 

00005500 

00005510 

00005520 

00005530 

00005540 

000C5550 

00005560 


09/02/74 


09/02/74 


09/02/74 
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FLAG  * • 0 • 3 ; 

end: 

_ ELSE 

00: 

SKIP(RINDEX)  * 0; 

FLAG  * flfB: 

end: 

/*  enter  in  stack  with  labelcsi  */ 

CALL  PUSHDGN  ( CMND , LABEL (RINDcA .*! ) 5 

TYPECRINCEXI  * LTYPEC4): 

levelirindex)  « clevel: 

call  stextclinei: 

end  block: 

/*  THIS  ROUTINE  STORES  COMMENT  STATEMENTS  */ 

COMMENT : PRCC|_  __ 

TYPECRINDEX)  * LTYPEC7): 

/*  ALL  COMMENTS  ARE  LEVEL  0 ♦/ 

LEVEL(RINCEX)  - 0: 

IF  (COUNT  = II  THEN  GO  TO  CSKIP; 

/*  GROUP  COMMENTS » SPACE  BEFORE  FIRST 
AND  AFTER  LAST  */ 

IF  TYPE! LINDE XCCOUNT-ONEB) ) * LTYPt(7l 
TFEN 

do: 

s >r  * SUBPTRC R INDEX!  ; 

IF  (SKIP(PT)  = TW03I  THEN 


NO 
- N> 

SKIP  ( PT ) = 3NE3 : 

NO 

ELSE 

SKIP  (PT!  = IB: 

SKIPCRINOEX!  = 35 

end: 

ELSE 

CSK IP : SKI  PC  RINDEX!  * TwJB; 

CALL  STEXTC  LINE): 

END  COMMENT: 

/*  CGFIND  ( OR  CGEND  ) SEARCHES  BUFFER  FOR 

Conceptual  groups  */ 

CGFIND:  PROC  (NSTtNENDI: 

XL  (LCTC2I  ,LToKC,JC,L2END,TENO.jENOi 
BIN  F I X ED (1 5 1 6 I t 
STYPE  CHARC4I  VAR, 

FT Y PE  CHARI4)  VAR  INIT  (••): 

/*  CONSiCER'EACH  GROUP  OF  HAlFCG 

STATEMENTS,  STARTING  AT  TJP  OF  BUFFER 
AND  CONTINUING  UNTIL  BJFFEk  BOTTOM 
~t  IS  HIT.  IF  TESTCG 

STATEMENTS  OF  A GROUP  ARE  OF  ONE 
TYPE  (ASSIGNMENT,  10.  OR  CALL! t 

RETURN  * OF  FIRST  CG  ST.. 

NENO  - A OF  LAST  CG  ST.  */ 

JEND  * HALFCG: 

TEND  * COUNT  - ONEB: 

LO:  NST.NEND  * IB: 


00005573 
0000558 0 
00005590 
00005600 
00005610 
00005620 
00005630 
00005640 
00005650 
00005660 
00005670 
00005680 
00005690 
00005700 
00005710 
00005720 
00005730 
00005740 
000C5750 
00005760 
00005770 
00005780 
00005790 
30005800 
00005810 
00005820 
00005830 
000 C 5840 
00005850 
00005860 
00005870 
00005880 
00005890 
000 05900 
00005910 
00005920 
00005950 
00005940 
00005950 
00C05960 
00005970 
00005980 
00005990 
00006000 
00006010 
00006020 
00006030 
00006040 
00006050 
00006060 
00006070 
00006080 
00006090 


RUN  NO.  7231 


DATE  C9/02/7* 


TIME  123o 


LI  ST INo  OF 


* 


Li:  .00  JC  * CNEii  TO  JENO : 

LCT  * Za: 

L2EN0  * JC  ♦ HALFCG  - ONEB; 

L2 : DO  KC  = JC  TO  L2EN0 ; 

STYPE  = T Y°E ( L INDEX! KC ) ) : 

/*  CENTERS  FOR  CALL.  IC.  ASSIGN  oT.  */ 

DO  LT  = 1 TO  3; 

IF  LTYPE(LT)  = STYPE  THE.. 

co: 

LCTJLTI  = LCTILTI  *■  CNci: 

IF  LC TILT)  * TESTCG  THEN 
CO* 

F1YPE  - LTYPECLT)  ; 

NEND  » KC; 

GC  TO  L3: 

ENC: 

END  L2: 

/*  NO  CG  IF  NEND  IS  STILL  0 */ 

IF  (NEND  = ZB  I THEN 
GO  TO  L4: 

/*  FOUND  CG.  DOES  IT  EXTEND  FATHER  ? */ 

L3:  IF  (NEND  = T END ) THEN 

GC  TO  FIRST; 

00  KC  - NEND  ♦ ONEB  TO  TEND: 

IF  TYPE  ( L INDE X( KC ) ) * FTYPc  THcN 
NEND  = KC; 

ELSE 

GC  TO  FIRST; 

end; 

/*  FIND  FIRST  C3-TYPE  STATEMENT  */ 

FIRST:  DO  KC  = JC  TO  JC  ♦ HALFCl,  - 1ESTCG; 

IF  T YpE ( L INDEX ( KC  N * FTTPfc  THEN 

co; 

N ST  = KC: 

RETURN; 

end: 

la:  end  Li: 

/*  NO  CG.  NST  AND  NEND  STILL  J */ 

return: 

/*  ENTER  HERE  TO  SEARCH  FOR  Co  IN 

PARTIALLY  FILLED  BUFFER  AT  cND  ♦/ 
CGEND:  ENTP Y < NST .NENO)  ; 

JEND  *" CCLNT  ♦ ONEB  - HALFCG; 

TEND  - CCUNT: 

GC  TO  LO: 

INC  CGFIND: 


XPAGE ; 

/*  *********  page  36  IN  HANDWRITTEN  COPY  ♦**♦*♦***  */ 


/*  PROCESSES  CALL.  GC  TO.  EXIT.  STOP.  WAIT. 
~ DELAY.  RETURN  STATEMENTS  */ 

CTRLC:  PRCC: 


VLASICH 


f 


PAGE  14 


00006103 
OOOC6 1 1 J 
COO J612  ) 
03006130 
0u0C6l40 
J0006153 
J 000616 J 
000C6170 
00006130 
00006190 
00006200 
00006210 
00006220 
000C6230 
00006240 
00006250 
00006260 
000C627D 
00006280 
00006290 
00006300 
00006310 
00006320 
0000633 0 
00006340 
00006350 
00 006360 
00006370 
00006380 
00006390 
OOGC64O0 
00006410 
00006420 
U0006430 
00006440 
000C6450 
00006460 
00006470 
000C648 0 
000C6490 
00006500 
00006510 
00006520 
00006530 
00006540 
003C6550 
00006560 
00006570 
00006580 
00006590 
00006600 
000C6613 
00006620 


Moor*  tvlirtf  * Jr 


FUN  NO.  7231  OATE  C9/02/74  TIME  123d  LISTING  OF 


• /*  ENTRY  FOR  CALL  */ 

TYPE(R INDEX)  = LTYPE ( 3 1 5 
IF  (CCUNT  * ONEB)  THEN  GO  TO  0.4C1 5 
/*  FIND  PRECEDING  LINE  SKIPCOOc.  NJ 

SKIP  BETWEEN  SUCCESSIVE  CALLS  */ 

PT  * SUBPTR(RINOEX) 5 

IF  ISKIPIPT)  = 5)  C (TYP£(LINOtX( COUNT  - ONEB) ) 

* L1YPEC3))  THEN 
SKIP(PT)  = za; 

CNC1 : SKIP(RINDEX)  * 5; 

QNC2 : IF  (PLEV-*0)  THEN 

OC: 

LEVEL! RINOE  X)  = PLEV; 

PLEV  = 0: 

end: 

ELSE 

LEVEL! RINDEXI-CLEVEL: 

CALL  STEXTILINE); 

return; 

/*  ENTRY  FOR  GO  TO  ST.  */ 

CTRLG:  ENTRY: 

TYPE!R INDEX ) = LTYPE ( 4 ) ; 

GO  TO  CNCl: 

/*  ENTRV  FOR  ALL  OTHER  CONTROL  ST.  */ 

CTRLO:  ENTRY; 

TY PE ! R INDEX  I * LTYPE ! 4) ; 

SKIPIRINDEXI  = 3: 

GO  TO  dNC2: 

ENO  CTRLC  • 

DECLARE:  PRCC; 

/*  FOR  DECLARATIONS#  ALLOCATE  AND  DEFAULT  ST.  */ 
DCL  ! NCHA  R • L ) BIN  FIXEDU5.0), 

SLEV  DEC  FI XEO! 21 ; 

/*  FIRST  LINE  OF  STATEMENT  ♦/ 

LEVEL!R INDEX)  * ClEVEL: 

TYPE !R INDEX ) = LTYPE!5) : 

SK  IP (P INDEX ) * ONEB; 

NCHAR  - 5 ; 

/*  SUdST  •DCL1  FOR  FULL  WORD  ♦ / 

IF  ! SUBSTR! LINE. 1.7)  = • DECL ARE • I THEN 
LINE  = *OCL • II  SUBSTRlLl YE.d) ; 

/*  SEPARATE  PHASES  : FIND  FIRST  COMMA 
NOT  IN  OUOTE  OR  PARENS  */ 

FCCMMA:  CALL  FINDCOM!L): 

TEMLINE  * SUbSTR! LINE.1.L) ; 

/♦FIRST  LINE  STARTS  AT  CURRENT  MATGIN  */ 

IF  INCHAR  * 5)  THEN 
GO  TO  PUT1 ; 

/*  FOR  OTFER  LINES  ♦/ 

/*  FIND  MARGIN.  PREPARE  TO  STORE  */ 

IF  SUBSTR! TEMLINE. 1.2) =BRK! 6)  THEN  DOS 
TLiNE*LINE: 

L*INDEX!  TEMLINE  . BRM  7)  ) + 1 ; 


VL/SICH 
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00006630 
00006640 
00006650 
00006660 
00006670 
0 OOC668O 
00006690 
0GGC6700 
00006710 
030C6720 
00006730 
00006740 
000C6750 
00006760 
00006770 
00006780 
00006790 
00&C6800 
00006810 
0 00C6820 
000C6830 
00036840 
00006850 
00006860 
00006870 
00006880 
00006890 
00006900 
00006910 
00006920 
00006930 
00006940 
00006950 
00006960 
00 006970 
00006980 
00006990 
00007000 
003C7010 
000C702D 
00007030 
000C7040 
00007050 
00007060 
00007070 
00007080 
00007090 
00007100 
00007110 
00007120 
00007121 
00007122 
00007123 


09/02/74 

09/02/74 

09/02/74 


Moor« 


DATE  C9/02/74 


TIME  12iti 


LISTING  OF  MODULE  VLASICH 
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RUN  NO.  7231 


LINE=$UBSTR(TEMLINE#l#U  5 
CALL  COMMENT: 

line=tline  : 

GO  TO  PUT1A: 

END: 

IF  I VERIFY! SUBSTRITEMLINE.1# 1) , 1 012  3456789 • ) 

= ZBI  THEN 

SLEV^DEC! SUBSTRC  TEMLINE.1. IN0EX(TEML ine# 1 

__ else_ 

SLEV  = is 

LE VEL (R I NOEXI  * CLEVEL  «•  SLEV; 

SK  IP  ( R INDEX ) = ZB: 

PREFIXCRINOEX.*^*  • ; 

TYPE (RINDEX )= • • ; 

LABEL (R INDEX#  * Is 1 1 1 

/♦  STORE  PHASE  IN  BUFFER  *'/ 

PUTl:  CALL  STEXT  ( TEMLINE) « 

/♦  MOVE  LINE  UP  OPERATE  ON  NEXT  PART  ♦ / 

PUT1A: 

LINE  * SLBSTRCLINE.L  ♦ II; 

/♦  DELETE  leading  BLANKS  */ 

I F VER  TF  Y (LINE  , BLANK  I -»»0'  THEN 

LINE  * SUBSTR(LINE.VERIFY(LINE. BLANK) I 5 
/♦  FINISHED  ? ♦ / 

IF  LINE  THEN 

GO  TO  dclend: 

N>  /♦  NO.  REPEAT  ♦ / 

TS  nChar  * ones; 

RINDEX  * ADOPTR(RINDEX) S 
GO  TO  FCOMMAS 

DCLEND:  IF  SKIP(RTNDEX)  * QNEB  THEN 

SKIP(RINDEX)  = TWOB; 

ELSE 

SKI PfR I NDE  X ) * 3: 

END  declare: 

/♦  ELSE  IS  CALLED  BY  PUSHPUL  ♦/ 

EL SET  PROC: 

TYPE ( R INDEX ) = LTYPE ( 4) ; 

SK  IP ( RINDEX ) = ZB: 

/♦  POP  UP  USED  UP  IFS  ♦ / 

DO  WHILE! STACKl**ELSE • ) • 

CALL  POPUPI^LSE1); 

CLE  V~EL*ST  ACK3-1 : 

CALL  POPIF; 

end; 

/♦  Check  for  matching  "if  ♦/ 

/♦  GB  ♦ / 

IF  STACK1-='IF*  then  do: 

“PUT  SKIP  LIST! •♦♦ERROR  IN  IF. ..ELSE  STr JCTURE** • ) l 
STOP; 

end; 

/♦  END  OF  GB  ♦/ 

/♦  ENTER  IN  PUSHDOWN  LIST  WITH  NJLL  LABEL  ♦/ 


• l-l  )#2# oi : 


0C0C7124 
000071 25 
000C7126 
00007127 
0G007128 
00007130 
00007140 
000C7150 
00007160 
00007170 
00007180 
00007190 
00007200 
00007201 
00007202 
00007220 
000C7230 
00007240 
00007241 
000C7250 
00007260 
00007270 
00007280 
00007290 
00007300 
00007310 
00007320 
W<T07330 
000C7340 
00007350 
00007360 
000C7370 
00007380 
O0OO739O 
000C7400 
00007410 
00007420 
OOOC7440 
00007450 
00007451 
00007452 
00007453 
00007454 
000C745  5 
00007456 
00007460 
000C7470 
03007471 
00007472 
00007473 
00007474 
00007475 
00007490 


09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 


09/02/74 


09/02/74 

09/02/74 

09/02/74 


09/02/74 


09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 


> 


DATE  C9/02/74 


TIME  123b 


LISTING  OF  MODULE  VLASICH 


FUN  NO • 7231 


FLAG-'C'S: 

CALL  PLSHD3N4 •ELSE  1 tMTLABI • 

CLEVEL*STACK35 

LEVEL(RINDEX)*CLEVEL-i; 

/*  IS  ELSE  FOLLOWED  BY  SEMICOLON  (EMPTY)  */ 
TEMLINE  * SUB STR 4 LINE  *5) ; 

TEMLINE  * SUB  STR( TEML I NE  »VER IF Y ( TEMLINE  « BLANK  I ) S 
IF  (SUBSTRITEMLINEt  Ml  * BRK4  ill  THE  4 
00?  _ __ 

CALL  STEXT4  LINE ) • 

THFL  * TWOB; 

RETURN; 

END; 

/*  ELSE  IS  FOLLOWED  BY  TEXT * SEPARATE 

_ ELSE  _ ♦ / 

CALL  STEXT4 #ELSEf I ; 

/♦  REMAINING  TEXT*  NEW  LINE  */ 

IF  SUbSTRC  TEHL INE • 1*2 )*BRK46)  THEN  DO; 
RINDEX^AODPtRCR INDEX) : 

TL  INE*L INE • 

L=|NDEX4TEMLINE*BRK47I)«T ; 

L I N E * S U B S T R 4 T E ML  I NfTTtL ) ;" 

CALL  CCPMENT; 

LINE *T LIKE; 

T E ML I N f»SUB  STft ( TEM  L I NE • L*  17  ; 

TEMLINE* SUB STR 4 TEMLINE  * VERIFY ( TEMLINE* BLANK  I ) ; 


END; 

RINDEX  * ADOPTR(klNDEX); 

count*count«-oneb; 

LINDE X(COUNT|»RINDEX; 

LINE  * TEMLINE; 

/*  ANY  PREFIX  7 */ 

CALL  rlabel; 

/*  IS  THTS  ON  IF  OR  WStAtEmEnT  +T 
CMND  * SUBSTR(LINE*l*3l; 

IF  CHNO* • BEGIN  • I CMND*1 BEGI N ; • I 

c mnd*  • Dir  ^nrrMNir* 1 oo;  then-  ixe  v el  *cxfvec=it 


END  else; 

FINOCOM:  PROC(LL); _ 

/*  EXAMINES  LINE/RETURNS  LL  = POSTION  OF 
FIRST  COMMA  NOT  IN  QUOTES  UR  PARENS* 
IF  NONE*  LL  * LENGTH  (LINE).  */ 

XL  ( KC * PAREN  *LL ) BIN  FfXEO(  15*01*  ~ 

QUOTE  BIT(l)  INIT4«09B>* 


Lis 


KCHAR  CHAR; 

PAREN  * ZB; 

00  KC  * 1 TO  LENGTHCLINEI  - 1* 

KCHAR  * SUB STRCLlNE* KC*1 1 * 

/*  UONT  TrmriNSrDF  0U0TE5‘0R  PARENS  ~*7 


BRKC21!  £ (PAREN  * ZB)  £ 4 -QUOTE  I 


IF  (KCHAR  » 

THEN 

So  To'TEom;  

/♦  IS  IT  CUOTE  OR  PAREN  7 


OOOC75DO 
00007501 
300075 02 
00007503 
00007520 
000C7530 
030C7540 
00007550 
00007560 
000C7570 
00007580 
00007600 
000C7610 
00007620 
000C7630 
0O0C7640 
000C7650 
00007651 
00007652 
00007653 
00007654 
00007655 
00007656 
00007657 
00007658 
00007659 
00007660 
00007661 
00007662 
00007663 
D0007670 
00007680 
00007690 
OOO07TOO 
00007710 
00007720 

00007711 

00007810 
00007820 
00007830 
00007840 
00007850 
00007860 
00007870 
OOOC7880_ 
00007890 
00007900 
00007910 
00007920 
00007930 
OOOC7940 
00007950 
00007960 


09/02/74 

09/02/74 

09/02/74 

09/02/74 


09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 


09/02/74 

09/02/74 


09/02/74 

09702/7* 


Moor#  Bu»m#n  roimv 


r 


DATE  C9/02/74 


TIME  1 23^ 
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FUN  NO.  7231 


t 


1 


IF  (KCHAR  * 8RK( 1 ) ) THEN 
DO: 

OLOT6  * -QUOTE  : 

GO  TO  L35 

FND; 

IF  (KCHAR  * BRK( 4 1 I THEN 

paren  * paren  ♦ cneb; 

ELSE 

IF  (KCHAR  = 3RK ( 5 ) J THEN 

561 

PAREN  - PAREN  - ONES: 

IF  PAREN  < ZB  THEN 

5CTTD  P^RHCRf“ 

enc: 

L3: END  Li:  

IF  ( QUOTE  I T (PAREN  -*  0)  THEN 
GO  TO  P ERROR; 

L4;  LL  » LENGTH(LINE) ; 

RETURN; 

/*  FOUND  COMMA  */ 

FCOM:  LL  * KC: 

RETURN; 

PERROR:  PLT  SKIP  LIST  ( •♦♦UNBALANCED  PARENS  OR  CUOTES**f > : 

GO  TO  L4s 
END  FIND COM; 

M IF:  proc; 

ho  DCL  L BIN  FIXED!  15*0  ; 

/*  FOR  EACH  IF  CLAUSE  */ 

FLAG  * M^B: 

OVER:  TYPEIRINOEXl  * LTYPE(4>; 

SK  IP(  R INDEX)  * ZB; 

/*  ENTER  IN  PUSHDOHN  LIST*  NULL  LABEL  */ 

CALL  PUShDON  ( • IF  • * MTLABi • 

LEVEL  (R  INDEYH^L1VEL-1  ; 

/*  SEPARATE  FIRST  PHASE  THRU  THEN  ♦/ 

L * INDEX (LINE* 1 THEN  •); 

re~L“’rB~THFJT 

DO: 

L * INDEX! LINE  • • THEN; • I ; 

IF  L * ZB  THEN  ~ ' 

GO  TO  thenerr; 

/*  FOUND  •then;*.  EMPTY  CLAUSE  */ 

ELSE 

co; 

TLINE*SUBSTR(LINE«1«L+*) : 

CALL  STEXT ( f LINE! ; 

GO  TC  TESTFN; 

END; 

END  ; 

/*  FOUND  #THEN  • */ 

TL INE*SUBSTR( LINE*1*L*4) ; 

CALL  STEXT(TLINEI  ; 

/*  UPDATE  PTR • LINE*  DELETE  LEADING  BLANKS  ♦/ 


00GC797D 
00007980 
00007990 
00008000 
00008010 
00008020 
00008030 
00008040 
00008050 
00008060 
00008070 
00008030 
00008090 
00008100 
00008110 
00008120 
00008130 
00008140 
00008150 
00008160 
00008170 
00008 180 
00008190 
00008200 
0000821D 
00008220 
00008230 
00008240 
00008250 
00008260 
00008270 
00008280 
00008290 
00008300 
00008310 
00008320 
000C83T0 
00008340 
00008350 
00008360 
00008370 
00008380 
00008390 
00008400 
00008410 
00008411 
00003412 
00008430 
00008431 
00008440 
00008450 
00008451 
00008460 


09/02/74 


09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 


r 


FUN  NO.  7231 


OATE  C9/02/74 


TIME  12 J6 


LISTING  OF  MODULE  VLASICH 
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RETs 


LINE  * SLBSTR I LINE «L  ♦ 6): 

LINE  * SUESTR  I LI NE. VERIF YILI NE . BLANK)  I • 

I F SUBSTRILINE. 1.2)*QRK!6)  THEN  JO: 

rindex*addptr<rindex) ; 
tlinf*line: 

L*INDEX( TLINE  *BRK( 7) ) *1 ; 

L INE- SUBSTRI TLINE.l.L) 5 
CALL  CCMHENT: 

L INE*  SUBSTRI TLINEtL«-ll  5 
LINE*SUBSTR(LINE.VERIFYILIN6. BLANK)  ) ; 

ENO; 

RINOEX  * AOOPTRIRINOEX) ; 

CGUNT*COUNT+ONEB; 

LINDE  XI COUNT )*RINDEX: 

/♦  CHECK  FOR  PREFIX  FOR  NEW  LInc  */ 

' CALL  RLABEL: 

IF  SUBSTRI LINE.1.3)S>DQ  1 I SUBSTAIL1 NE.l . 3 ) * #00; • I 
SU6STRILINE. 1.6)S*BEGIN  • I SUBSTRI L INE t l *6)a 
THEN  C L £ V £ L*C LE VE  L- 1 : 

/♦  ANOTHER  IF  7 */ 

IF  I SLBSTRCLINE.1.3)  = #IF  •)  I 

I SUBSTRI LINE. 1 .3)  * f IF!  *T  THEN 
GO  TO  OVER; 

THFL  * IS 


•BEGIN;* 


r>o 

HS5- 

OO 


return: 

/*  NO  • THEN • f PRINT  MESSAGE.  FUDGE.  GO  ON  ♦/ 

THENERR:  PUT  SKIP  LIST!  •♦♦MI  SSI  Ni.  ilThbN,#  IN  IF  STATEMENT*^) 

PUT  SKIP; 

CALL  STEXTILINE): 

/♦  RETURN  TO  MAIN 
GO  TO  P3: 

ENC  if: 

IOSUB:  PROC: 

PROCESSES 
AND  AFTER 


PROGRAM  */ 


/♦ 


lOT  STATEMENTS.  SKIP  LFn£~ 
EACH  10  OR  GROUP  OF  10  S 
TTPt!tI»©fXl  * LTYPEI2); 

W IPLEV  -**  01  THEN 
OC: 

LEVEL! RINOEX)  - PLcVS 


BEFORE* 

♦/ 


PLEV  * o: 

end: 

ELSE 

LEVEL IRTnOEX)^  CLt VEL : 
/*  IS  PRECEDING  STATEMENT  ALSU  10  7 
IF  COUNT  * l THEN  GO  TO  111; 


♦ / 

i > T*HEN~ 


DO; 

PT  * SUBPTRIRINOEX) ; 
TFHTK  TPT  PTT  "=’T  WJET  THEN 
SKIPIPT)  * ONEB; 

ELSE 

ZB: 


SKIPIPT) 
SKIPIRINOEX)  * 


3S 


00008470 

00008490 

00008481 

09/02/74 

00008482 

09/02/74 

00008483 

09/02/74 

00003484 

09/02/74 

00008485 

09/02/74 

00008466 

09/02/74 

00008487 

09/02/74 

00008488 

09/02/74 

00008489 

09/02/74 

00008490 

00008491 

09/02/74 

00008492 

09/02/74 

00009500 

00008510 

00008511 

09/02/74 

00008512 

09/02/74 

00008513 

09/02/74 

00008520 

00008530 

00008540 

00008550 

00008560 

00008570 

00008580 

1 00008590 

00008600 

00008610 

00008620 

00008630 

OOOC8640 

00008650 

00008660 

00008670 

00008680 

OC0O869O 

00008700 

00008710 

00008720 

00008730 

00008740 

“00008750 

00008760 

00008770 

00008780 

00008790 

O00G8800 

00008810 

00008820 

00008830 

00006840 

00DC8B50 

Moo  if  Buvntvi  re*»m. 


DATE  C9/02/74 


TIME  123d 


» 
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n 


RUN  NO.  7231 


ENC  : 

ELSE 

111:  SKIP(RINDEX)  * TWJo: 

/*  ENTER  IN  BUFFER  */ 

CALL  STEXT(LINE): 

END  IOSLB: 

MOVUP:  PROCITHRCCII 

/*  CALLED  AFTER  OUTPUT  TO  MOVE  JP  kEMAING  BUFFER 
LINES.  ACTUALLY  CNLY  THE  LINUcX  TABLE  IS 
CHANGED  (POINTERS  TO  FIRST  LXNc  OF  EACH  STATEMENT 
IN  BUFFER ( • COUNT  IS  THE  NJ.MdER  OF  STATEMENTS 
IN  euFFER.  THROO  IS  THE  NUMdER  OF  LAST  ST 
TO  BE  MOVED  OUT.  LPOATES  CUJNT. RINDEX  */ 

DCL  ( THACC. JCT ) BIN  FIXEDU5.0); 

COUNT  = COUNT  - THROO; 

IF  COUNT  = ZB  THEN 

return; 

DO  JCT  * 1 TO  COUNT; 

LINDEX(JCT)  * L I NDEX( JCT  «•  THROO)! 

END; 

/*  ZERO  LKUSEO  INDICES  */ 

DO  JCT  * COUNT  t 1 TO  20! 

L INDEX!  JCT)  « ZB*. 

end; 

i END  MOVUP; 

ONSUB:  PRCC; 

ro  /*  PROCESSES  ON  CONDITION.  SIGNAL  AND  REVERT 

133  " ‘ STATEMENTS.  prededes 

STATEMENTS.  PRECEDES  EACH  d Y BLANK  SPACE  AND 
OOTTED  CINE.  FOLLOWS  BY  DOTTED  lI  NE  » UNLESS 
~BN  St. “INCLUDES  A BEGIN  GAJJP.  WHEN 
ONFLAG  IS  SET  TO  1 AND  Trie  FJLcOwING  DOTTED 
LINE  IS  IMPLEMENTED  AFTER  THE  CORRESPONDING 
END.  */ 

DCL  LL  FIXED  BIN(IS.O) : 

TYPE (RINDEX ) * LTYPE ( 6) : 

IF  (PLEV  -=  0)  THEN 

DO*.  LEVELIRINDEX)  = PLEv: 

PLEV  = 0 : 

END: 

ELSE 

level(rinoex)  = clevel; 

SKIP(RINOEX)  « 7; 

/*  IS  LAST  (NON-BLANK)  WORK  • BEGIN  * 7 */ 

IF  LENGTH(LINE)  < 7 THEN 
GO  TO  TSTOR: 

Ll:  DO  LL  * LENGTH(LINE)  - l TO  o BY  -l; 

IF  SUBSTRILINE.LL.l)  * BLANK  THeN 
GO  TO  L2: 

IF  SUBSTR(LINE.LL— 5.6)  * * BEGIN*  THEN 
DC  • 

VnFLACT  * ~fl  •&: 

SK I P ( RINDEX ) = 6; 


JOOC  3 360 
000C8870 
00008880 
300C8890 
00008900 
00008910 
00008920 
0Q0C8930 
J00C894U 
00008950 
00008960 
00008970 
000  C 89 80 
00008990 
00009000 
00009010 
00009020 
00009030 
00009040 
00009050 
00009060 
00009070 
00009080 
00009090 
00009100 
00009110 
00009120 
000091*30 
00009140 
00009150 
00009160 
00009170 
00009180 
00009190 
00009200 
00009210 
000C9220 
00009230 
OOC  09240 
00009250 
00009260 
00009270 
00009280 
00009290 
00009300 
00009310 
000C9320 
00009330 
00009340 
00009350 
00009360 
000C9370 
00009380 


VujiOj  tuuimg  4joc/» 


RUN  NO.  7231 


DATE  C9/02/74 


THE  123* 


r 


LISTlfw  CF  K JOULE  VL  A > I CM 


ENC  : 

GO  TO  TSTGR  S 
12  s END  US 
TSTOR:  CALL  STEXT (LINE  I 5 

END  ONSLB: 

OUTPUTS  PRCC ( THRU I S 

/*.  PRINTS  STATEMENTS  1 - THRU  */ 

/*  WRITTEN  FOR  30  OR  12  0 COLUMN  PRINTOUT 
ON  SYSTEM  FILE  */ 

DCL  (RI.THRU.  N V.  LASTN.  I)  BIN  FIaED(15.0). 

(LEV.  MCI  DEC  FIXED  (3.J). 

( CM  TB  INIT  ( •/♦  • I « CMTE  INIT  (•  */•>)  CHAR(3); 
IF  THRU  - ZB  THEN 

retlrn; 

_ /*  ALL  LINES  ARE  AT  SAME  LEVEL  (RULE  1)  */ 

LEV  = LEVELC  L INDEX! 1 I I S 
MC  * MARGIN(LEV)  «■  1 S 

/*  FIND  POINTER  TO  LAST  OUTPUT  LINE  */ 

IF  THRU  * COUNT  THEN 
LASTN  = RINDEXS 

EL  SE 

LASTN  = SUBPTRIL INDEX! THRU  ♦ 11); 

Rl  * SUePTR(LlNOEX(ll)  S 
/*  PRINT  CNE  LINE  AT  A TIME  */ 
i LPOs  DO  I = I TO  50; 

RI  = ADOPTR(RI); 

LEVELS VEL ( RI  I S 

o " “ 'mC^marginilEvKi: 

/*  IS  IT  COMMENT  ? */ 

IF  TYPE ( R 1 1 - LTYPE ( 7 I THEN 
DC: 

OCMT : PL T FILE! SYSPRINT)  EDIT 

<CMTB.TEXT<  RI) .CMTE  . SEO#(R III 
(COL (2  I . A . A .COL ( NCOL—2 I » A • X(4) .A) ; 

GO  TO  LPA  : 

/*  GB  */  END: 

7*  NOT  COMMENT;  IS  TEXT  NULL  ? */ 

IF  TEXT ( R 1 ) = ••  THEN 

DC  S 

Nf XT S ~ PUT~  FILE ( S YSPRINT  f EDIT( PREF IX4RI .*) « 
LABEL(RI.*).LtV.SEOY(RI>) 

(C0LI2I.10  A.C0L(NC0L*2).F(2) .X(l).A); 

GO  TO  LPA : 

ENDS 

/*  LINE  FAS  TEXT  */ 

Yxf7~  " PLT  FILE!  SYSPR  INTI  EDIT 

( PREFIX (RI .*) . LABEL ( R I • * I . 

TEXT ( RI  I * LEV.  SEOM  RI  I I 

( COL ( 2 I . (iOlA.  COL(MC).  A.  C0L(NCQL+2I. 
F(2J.X(1).A); 

L P A s IF  RI  = LASTN  THEN 

GO  TO  LPOUTS 
LPEs  ENC  LPOS 


3000^39 J 
00009400 
C0009410 
00009420 
000C9430 
00009440 
000C9A-50 
0000946 } 
00009470 
00009480 
00009490 
00009500 
00009510 
00009520 
00009530 
000C9540 
00009550 
00009560 
00009570 
000095 BO 
00009590 
00009600 
00009610 
00009620 
00009630 
00009640 
00009641 
D0009642 
00009650 
00009650 
00009670 
00009680 
00009690 
00009691 
00009710 
00009711 
00009720 
00009730 
000C9740 
000C9750 
00009760 
00009761 
000097Q0 
00009790 
00009800 
00009810 
O00C9820 
00009830 
00009840 
00009850 
00009860 
00009870 
00009880 


09/02/74 

09/02/74 


09/02/74 

09/02/74 

09/02/74 


09/02/74 

09/02/74 


09/02/74 

09/02/74 
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/*  ALL  LINES  PRINTEO,  LOOK  FOR  AFTER  SHI » UR  CCT  */ 

/*  BY  RULES  2 £ 3 • ONLY  LAST  Li  Ve  l AN  HAVE  FCLLCrflNG  SKIP 
DOT  */ 

LPCUT:  IF  SKIP! LASTN)  * 0 THEN 

return: 

ELSE 

NV  * SKIPCLASTN): 

/*  PRINT  DOT,  SKIP  */ 

PUNC:  IF  (NV  * 5)  I (NV  = 4)  THEN 

IF  (NCOL  * 72)  THEN 

PUT  FILE(SYSPRINT)  EDIT 
(CMTB,  (65)  •.*,  CHTE) 

TCOL(2),  A,  A,  COL(7D).  A); 

ELSE 

PUT  FILE(SYSPRINT)  EDIT 
( CMTB,  (112)  •.*,  CMTE) 

( CCL(  2)  , A,  A,  COL  (1171,  AC 

if  (nv  = j)  I (nv  * 3 ) then 

PUT  SKIP: 

RETURN: 

/*  IF  VERY  FIRST  STATEMENT  HAS  PRE-SKIP 
EtC/.  ENTER  HERE  */ 

OUTFST : ENTRYINV2C 

IF  ( NV2  = 1)  THEN 


ro 

-AX- 


EL SE 


NV  » 3: 

IF  (NV2  = 6)  THEN 


ELSE 


PENC: 


Nv  = 5: 

IF  (NV2  = 3)  THEN 

Nv  = a; 

GO  TO  PUNC: 

END  OUTPUT: 

PROC: 

/*  PROCESSES  END  ST*  WHICH  HAY  TERMINATE 
PROC.  DO*  OR  BEGIN  BLOCK.  viPOATtS 
POShCOwN  LIST  AND  LEVEL  */ 

DCL  LAB  CHAR  (3D  VAR; 

XL  LVAR  LABEL  CFAN3*  PLAINU: 

OCL  CLINC.  IFANI  BIN  FIXED! 15.01 : 

TYPE (R INDEX ) - LTYPEC4): 

LEVELCRINDEX)  * CLEVEL: 

~ /**  skip  if  This;  is  end  of  a condition  block 

/*  BEGINNING  GB  */ 

IF  CN FLAG  THEN  SKIP(RINDEX) 

else  skiP(RiNbEX)=Z&; 

/*  store  text  */ 

call  stextiline); 

IF  (ONFLAGI  THEN  DO: 
cnflag*,o,b: 
return; 


*/ 


END: 


/*  END  OF  GB  */ 


GOG  09  890 
QR  0G0J9900 
00009910 
00009920 
00009930 
000C9940 
00009950 
00009960 
00009970 
0 J0C9980 
0O0C9990 
00010000 
0001001 J 
00010020 
00010030 
00010040 
00010050 
00010060 
00010070 
00010080 
00010090 
00010100 
00010110 
00010120 
00010130 
00010140 
00010150 
00010160 
00010170 
0001018C 
00010190 
00010200 
00010210 
00010220 
00010230 
00010240 
00010250 
00010260 
00010270 
00010280 
00010290 
0001030 0 
00010310 
00010320 
00010321 
00010322 
00010323 
00010324 
00010325 
00010326 
00010327 
00010323 
00010329 


09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 


PUN  NO.  7231 


DATE  C 9/02/74 


TIME  12J<* 


LISTING  CF  M30ULE  VLAS1CM 


PAGE  23 
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/*  IS  END  FOLLOWED  BY  IDENTIFIED  7 */ 

temline  * substrilinf.4) ; 

TEMLINE  * SUBSTRITEMLINE.VERIFjflTEMLlNE.BLANKl) 
IF  LENGTHITEMLINEI  * 1 THEN 
GO  TO  PLAIN; 

/*  SET  IDENTIFIER  INTO  LAB  */ 

/*  GB  */ 

FANCY;  LA8=SUBSTRI TEMLINE. 1. LENGTH (TEMLINE) -II  I I • 5 • 5 
LIND  * INDEX! LAB, BLANK)1_ 

IF  LIND  -»*  ZB  THEN 

/*  GB  */  LAB»SU9STRILAB, 1. LIND-11  II J 

/*  TEST  FCR  ERROR  IN  PUSHDOWN  LIST  */ 

FAN2:  LVAR  * FAN3: 

GO  TO  sterr; 

/* RETURN  HERE_IF  NO  ERROR  */ 

/*  DOES  IDENTIFIER  MATCH  STACK  LABEL  7 */ 

FAN3:  DC  IFAN  - 1 TO  5; 

IF  ISTACK2I IFANI  * LAB)  THEN 
f I STACK 1 “ 'ENTRY' I THEN 
GO  TO  ENTERRJ 

ELSE 

CO  TO  HA WIT ; 

/*  IDENTIFIER  NOT  IN  THIS  STACK  LEVEL  */ 

end;_  

IFSTACK i«  'ENTRY'  THEN 
FLAG  = 'O'B; 

ELSE 


N> 


flag  * '1'b; 

CALL  POPLPI STACK1 1 « 

/*  KEEP  LOOKING  FOR  LAB 
GO  T0TTAN2 ; 


*/ 


/*  JUST  END  NO  IDENTIFIER  */ 
/*  TEST  FCR  STACK  ERROR  */ 
PLAIN:  ' LVAR  * PL  A INI'; 

GO  TO  sterr; 

/*  RETURN  HERE  IF  OK 
~1FTTa£KI  1 
DO: 

FLAG 


PLAIN! : 


*/ 

entry'  Then 


• C'B: 


CALL  POPUP! STACK 1 I : 
GO  TO  PLAIN: 

ENC: 

/♦"  popup  l lFVEl  */ 

HAVIT : FLAG  - 'l'B; 

CALL  POPUP(STACKl) ; 

"IF  STACK l-'TF*  TfifFTTLEWL-sTSCKr; 

CLEVEL*STACK3; 

LEVEL1RINDEXI-CLEVEL*!: 


/*  ERROR  RETURSN*/ 

ENTERR:  PUT  SKIP  LIST! '**LABEL  ON  END  STATEMENT  SHOULD  NOT  MATCH  *|| 
•ENTRY  NAME**'! 

/*  TRY  TO  RECOVER*/ 


C3010410 

00310420 

00010430 

00010440 

00010450 

00010460 

00010470 

09/02/74 

00010471 

09/02/74 

00010480 

0001C490 

00010500 

09/02/74 

00010510 

00010520 

00010530 

00010540 

00010550 

00010560 

00010570 

00010580 

00010590 

00010600 

00310610 

00010620 

00010630 

00010640 

00010650 

00010660 

00010670 

00010680 

00010690 

00010700 

00010710 

00010720 

~00010730 

00010740 

00010750 

00010760 

0001C770 

00010780 

00010790 

00010800 

00010810 

00010820 

00010830 

00010840 

00010850 

09/02/74 

00010851 

09/02/74 

00010852 

09/02/74 

00010870 

00010890 

00010890 

09/02/74 

00010891 

09/02/74 

00010910 

1 
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GO  TQ  PLAINl; 

/♦  TEST  FOR  STACK  ERROR  ♦ / 

STERR:  IF  STACKl=*TOP*  I CLEVEL=0  THEN 
00  5 

PUT  SKIP  LIST! •♦♦UNMATCHED  END  OR  ERROR  IN  IF. ..ELSE  • I I 
* STRUCTURED*  1 5 

STOP; 

end; 

GO_TO  LVAR5 

END  PEND; 

POPIF:  PROC; 

/♦  POPIF  ICALLEO  BY  PlSHPULl  OR  ENTRY  POPEL 
(CaXUED  BY  ELSE  OR  PENdT  CctARi  PUSHDQHSf 
LSIT  fcHEN  IF » IF  ...  ELSE  PAIR*  OR  BLOCK 


0 JO  10920 
00010930 
00  0 10940 
00010950 
00010960 
00010961 
0001C980 
000109QQ 
00011000 
00011010 
00011020 
00011030 
00011040 
00011050 


IS  termint 

IS  TERMINATED*  CALLS  POPUP  TO  00  CLEARING.  ♦/ 
XL  ELFLAG  BITCl)  INIT(*OlBI; 

/♦  POPUP  TOP  • IF 1 ♦/ 

P'OPl:  F L A G - • 0 • B ; 

CALL  POPLP(#IF*l: 

/♦  IS  LIST  EMPTY  ? ♦/ 

END  POPIF; 

POPUP:  PROCCCMANDI ; 

/♦  POPS  LP  I STACK  LEVEL  IIN  EACH  OF  THE 

3 L I STSTT DECREMENTS  C LEVEL  IF  FLAG  * 1 ♦/ 

DCL  CM AND  CHARI^I  VARYING; 

/♦  NO  LEVEL  CHANGE  IF  ENTRY  OR  ELSc  ♦/ 

IF  ( FLAG)  THEN 

CLEVEL  * CLEVEL  - Is 
IF  (STACK1  -=  CMANDI  THEN 
DO  ; 

PUT  SKIP  LIST  (•♦♦ERROR  IN  STACKl****; 

stop; 

End: 

/♦  POPUP  1 LEVEL  IN  EACH  STACK  ♦ / 

FREE  ST ACK1 * STACK2 • ST ACK3 ; 

END  ~P0PUP1 

PUSHDON:  PRCC( CMAND. LABL I 5 

/♦  ENTERS  OP.  NAME  (E#G.  *IFM  IN 
STACK 1,  UP  TO  5 LABELS  IN 
STACK2*  CLEVEL  IN  STACK3. 

STORAGE  FOR  THE  STACKS  IS  CONTROLLED* 

ALLOCATED  IN  PUSHDON.  FREED  IN  POPJP  ♦/ 

DCL  CM AND  C HAR( ♦ I VAR. 

L A3L( 5)  CHAR ( ♦ ) VAR, 

X CEC  FIXED(2T; 

/♦  GET  PRESENT  LEVEL  ♦/ 

X * STACK3; 

~j+  Increment  level  unless  Entry,  else*  orTTF  *r 

IF  (FLAG)  THEN 

x * x + i; 

/♦  PUSHCCWN  EACH  OF  3 STACKS  *7 
ALLOCATE  STACK1*  STACK2C  51  * STACK3 ; 


00011060 
00011070 
00011080 
00011090 
00011103 
00011110 
00011120 
00011370 
00011380 
00011390 
00011400 
00011410 
00011420 
0001 1430 
00011440 
00011450 
00311460 
00011470 
00011430 
00011490 
00011500 
00011510 
00011610 
00011620 
00011630 
00011640 
00011650 
00011660 
00011670 
00011680 
00011681 
00011700 
00011710 
00011720 
00011730 
00011740 
00011750 
00011760 
00011770 


09/02/74 

09/02/74 

09/02/74 


09/02/74 


09/02/74 


09/02/74 

09/02/74 


09/02/74 
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RUN  NO.  7231 


DATE  09/02/7*  TIME  123<i 


STACK3 

STACK1 

STACK2 


X • 

chand; 

labl: 


/*  UPDATE  CURRENT  LEVEL  */ 

CLEVEL  * STACK3 • 

END  pushccn;  _ 

PUShPUL:  PROC: 

/*  CALLED  BY  PLEOIT  CR  RETURN  PRJH  READ  TO  CHECK  ON 
PRESENT  STATJS  OP  IF. ••ELSE  STkJCTURES  AND  DO  ANY 
NECESSARY  UPDATING  OF  THE  PUSHDOWN  STOCKS  */ 

DCL  L BIN  F I XED( 15*0; 

THFL  * C5 

/*  ELSE  STATEMENT  ? ♦ / 

IF  ! SUBS7R(LlNEtl*5)  * 'ELSE  VJ  I (SUBSTR 
(LINE  .1.5)  » •ELSE  : * I THEN 


do: 

CALL  ELSE; 

IF  THFL»TWOS  THEN  GO  TO  P3  : 

RETURN; 

end; 

/*  NO;  IS  TOP  OF  STACK  fIF»  ? ♦/ 

AGINi:  IF  STAClci* *1XSE#  THEN  CALL  POPUP!  • cLSE • FT 
IF  STACK1-* IF • THEN  00; 

00  WHILE! STACK1* • IF • I ; 


ro 

-U4~ 


CLEVEL*STACK3-l: 
CALL  popif: 
end: 


GO  TO  AGINI 5 
END; 

RETURN; 


00011780 
00011790 
0001 1800 
00011810 
0 0011820 
00011830 
00311840 
00011850 
00011860 
00011870 
00011880 
00011890 
00011900 
00011910 
00011920 
00011930 
00011940 
00011941 
00011950' 
00011960 
00011970 
00011980 
00011981 
00011982 
00011983 
00011984 
00011985 


O0O11986 
00011987 
00011990 
"00012000 
00012020 
00012030 
UOOl  2040“ 
00012050 
00012060 
00012070 
00012080 
00012090 


/*  Y £$7~ TP  St.  IS  COMPLETED.  CHECK  JFF~ 
end  pushpul: 
smarg:  proc: 


~*r 


/*  GIVEN  READ-ltt  VAL UES~OF  IMA R GTFTTT  MITTAL 

MARGIN)  AND  DELHARG  ( MARGIN  INCREMENT)  THIS 
SETS  UP  A TABLE  OF  MARGIN  VALUES  FOR  NESTING 
LIVE (7!Tl"— ~9 • CO M KENT  STATcMENfS  ARE"  LEvFL  1) 
AND  0 MARGIN  IS  DEFINED  AS  l */ 

XL  IMA  FIXED  BIN!15«0): 


MARGIN!!)  * IMARGIN; 

DO  I MAa2  TO  15; 

MARGIN  ! IMA ) * MARGIN  (IMA  - 1)  + DELMARG; 


END: 

END  SMARG: 

STEXT:  PROC  !SOMLIN): 

/*  WRXrfFN  FOR  80  OR  120  COLUMN  PRINTOUT  (NCOL 
OR  116).  STORES  STATEMENT  TEXT  IN  BUFFER  IN 
PRINT  LINE  OUANTA,  ALLOWING  FOR  PREFIXES  AND 

UlttTSl  DIVIDE 5"  TEXT  ST  SCRO  cnOS  TF  FOSSIBLE 

SEPARATES  FORE-AND-AFT  PARTS  OF  SKIPCODE  AND 
STORES  THEM  APPROPRIATELY.  */ 

XL  ICFL.COMFL)  BI tl  1 ) INITC  *0* B)  « 

XL  C LP  «LLtCC  ) BIN  FIXEDU5.0)  1NITU6); 


72 


00012100 
00012110 
00012120 
00012133 
00012140 
00012153 
~0 00121 60 
00012173 
00012180 
00012190 
00012200 
00012210 
00312220 
00012230 





09/02/74 


09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02/74 

09/02774 

09/02/74 


09/02/74 


- 
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n 
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* DCL  ( NCFA  R • MGt  RC  • Mt  FC.  WoKlPI  FIXEO  BINU5.0). 

TLE V DEC  FIXEDI2). 

SOMLIN  ChAR  I * ) VARYING: 

SEO#!R INDEX l*SEONG; 

TLEV  * LEVEL! RINDEX! ; 

MG  * MARGIN! TLEV! ; 

/*  SEPARATE  SKIPCODE  INTO  FQR/*FT  LOMPONENTS  */ 
WSKIP  = SKIP! RINDEXI : 

FC  * CHCCDE ! WSKI P * 1 ) ; 

RC  * CHCCDE! W SKI P «2 ! ; 

/*  COMMENT  HAS  DIFF'T  PUNCT.  . .*J  PREFIX  */ 

IF  TYPE!RINDEXI  * LTYPEI7)  THEN 
DO: 

NCFAR  * NCOL  - 7: 

CCMFL  - * i*b: 

GO  TO  AGAIN: 

END: 

/*  NOT  COMMENT  */ 

NCHAR  * NCOL  -MG: 

DO  NI  = 1 TO  5: 

LP  8 LP  ♦ LENGTH! PREF I X!  K INDEX . Nl J ) : 

LL  * "Lt  ♦ LENGTH!  LABEL T&TnDEx  *Nl  |TV 
END: 

/*  DO  PREFIX*  LABEL  NEED  SEPARATE  LINE(S)  ? */ 

IF  LP  ♦ LL  ->  MG  THEN 
GG  TO  AGAIN; 

K /*  YES*  TCO  LONG  */ 

IF  LP  » ZB  THEN 
GO  TO  A2: 

/*  PREFIX  PRESENT:  GIVE  IT  A LINE  */ 

CC  * CC  ♦ ONEB; 

SK  I P ! R INOEX ) = FC; 

PT  - ACCPTRIR INDEX) : 

LABELTR INDEX* *)»# • : 

TEXTIRINDEX)** • : 

rindex  = pt; 

TeSITr index )=SECNO: 

/*  now  label,  if  any  */ 

ENOUGH  TO  FIT  IN  MARGIN  ? */ 

IF  LL  <*  MG  THEN 
00: 

CFL  = ■ i*b: 

GO  TO  AGAIN; 

end: 

/*  LONGER.  SEPARATE  */ 

A2:  CC  * CC  «*  ONEB: 

IF  CC  = ONEB  THEN 

SKIPIRINDEX)  = FC: 

ELSE 

DO: 

SKIPIRINDEX!  * 0; 

; PREFIX!*  INDEX.*!*  •• ; 

typeirindexi-* • : 


00012240 

00012250 

00012 2b0 
00012261 
00012270 
00012280 
00012290 
00012300 
00012310 
00012320 
00012330 
00012340 
00012350 
00012360 
00012370 
00012380 
00012390 
00012400 
00012410 
00012420 
00012430 
00012440 
00012450 
00012460 
00012470 
00012480 
00012490 
00012500 
00012510 
00012520 
00012530 
00012540 
00012550 
00012560 
00012561 
00012570 
OGO 12  571 
00012590 
00012590 
00012600 
00012610 
00012620 
00012630 
00012640 
00012650 
0001266 0 
00012670 
00012680 
00012690 
00012T00 
00012710 
00012720 
00012721 


09/02/74 

09/02/74 


09/02/74 

09/02/74 

09/02/74 


09/02/74 

09/02/74 
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. END: 

TEXT (R  INDEX  ) = • 1 : 

LEVEL  <R INOEX)  = TLEV 5 
RINDEX  * ADOPTR(RINDEX): 

SEO#(P INDEX l-SECNJ; 

/*  SEPARATE  TEXT  INTO  PRINT  Li 4cS.  *TJRE  */ 

AGAIN:  CC  = CC  * ONE *3  ; 

/*  CAS?:  PR  * LABEL  < MARGIN  */ 

IF  CC  = CNEB  THEN 

SKIP(RINDEX)  * FC: 

/*  BUT  GENERALLY:  ♦/ 

; ELSE 

do: 

SKIP! RINDEX)  = 0; 

IF  I CFL I THEN 

CFL  * -«cfl: 

ELSE 

LABEL ( RI NDEXt ♦!  * 

PREFIXCRINDEX,*)  = 

IF  l-COMFL)  THEN 

TYPy  RINDEXI  * • 

ELSE 

TYPECRINDEXI  = LTYPEC7I; 

' _ end: 

LEVEL (RINOEX)  = TLEV : 

/*  WILL  TEXT  FIT  IN  THIS  LINE  ? */ 

UN  IF  LENGTH! SCMLIN)  <=  NCHAR  THEN 

^ 

TEXTIRINDEX)  * SCMLIN5 
GO  TO  T EXTOUT; 

end; 

/*  NO.  SEPARATE  BETWEEN  WORDS  */ 

DO  Nl  = NCHAR  TO  1 BY  -l: 

IF'  I SUBS  TR4  SO  ML  IN  .NI  VlT  * BLANK)  THEN 
GO  TO  LINOUT; 

end; 

7+  NO  BLANK  FOUND  */ 

NI  * NCHAR: 

LINGUT:  TEXTCRI NOEX)  = SUBSTRI SGML  I N • 1 • NI ) : 

SO  ML  IN  « SUBSTRI SGML  IN  . NI  ♦ 11  5 
IF  SGML  IN  = ••  THEN 
GO  TO  TEXTOUT; 

RINDEX  = ADDP  TRI R INDEX) : 

$E0#<RINDEX )=$EONO: 

GO  TO  AGAIN; 

7*  TEXT  tCMPLETE.  CORRECT  SKIP  FOR  9 AFTER  • */ 

TEXTOUT:  IF  CC  = ONES  THEN 

SKIP(RINOEX)  = WSKIP; 

ELSE 

SKIPCRINDEX)  * RC; 

/*  RETURN  */ 

END  SfEXT: 

/*  ALL  SUBROUTINES  AND  FUNCTIONS  HAVE  BEEN  INCLUDED  */ 


0G012730 
GO  H2740 
000127  50 
00012760 
00012761 
00012770 
00012780 
00012790 
00012800 
00012810 
00012820 
00012830 
00012840 
00012850 
00012860 
00012870 
00012880 
00012890 
00012900 
00012910 
00012920 
00012930 
00012940 
00012950 
00012960 
00012970 
00012980 
00012990 
00013000 
00013010 
00013020 
00013030 
00013040 
00013050 
00013060 
00013070 
00013080 
00013090 
00013100 
00013110 
00013120 
00013130 
00013140 
00013141 
00013150 
00013160 
00013170 
00013180 
0001319 0 
00013200 
00013210 
00013 220 
00013230 


09/02/74 


09/02/74 
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RUN  NO.  7231  DATE  C9/02/74  TIME 


123d 


-end  plfcit 
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CONCEPTUAL  GROUPINGS  PROGRAM  FOR  PL/1  (GP-P) 


6.  SOURCE  PL/1  PROGRAM  OF  (GP-P)  GROUPED 


238 


SOURCE  EDITED  BY  PLEDIT 


PAGE 


1 


PlFBTT:  procedur EOPT IONSIMAlN) : 

CCL  TL IN 5 VAR  CONTROLLED; 

DCL  ST  AT  €MENT_SIZE  FIXED  DECIHAH7»: 

DCL  MAX.LINES  FIXED  DECI MALI  71 ; 

CCL  SEONO  CHARI  6) ; 

CCL  CONT.CHAR  CHARI  it ; 

OCL  SY5PRINT  PRINT  EN  VI MEOIUMI SYSlST .ItJll  F RECSIZEI133)  BUFFERSI2)): 

DCL  CCIN  STREAM  INPUT  EN VI MEDI UM I S YSOD4 ,2540  I F RECSl ZE 180) I ; 

/*  /*  PART  1 INITIALIZATION  */ 

/*  /*  BUFFER  STORAGE  ♦/ 

/«■  /*  LINDEX  IS  POINTER  TABLE  TO  BUFFER  */ 

/*  /*  BUFFER  IS  6 ARRAYS.  EACH  DIMENSIONED  30  */ 

/*  /*  LABEL  "PREFIX  ALLOW  MAX  OF  5 TO  A ST.  */ 

DCL  L INDEX! 2C  ) FIXED  BINtlS.Oi  INITI!20)J). 

TEXT!*)  CHAR  1 1201  VAR  CONTROLLED. 

PREFIX!*.* I CHARI  31)  VAR  CONTROLLED. 

LABEL!*.*)  CHARI  31)  VAR  CONTROLLED. 

TYPE!*)  CHAR14)  VAR  CONTROLLED. 

LEVEL!*)  DEC  FIXEDI2)  CONTROLLED, 

SEO#(*>  CHAR  I 8)  CONTROLLED. 

SKIP!*)  BIN  FIXEO  CONTROLLED; 

/*  /*  COUNT  *"  NUMBER  OF  CURRENT  STATEMENT.  RINDEx  IS  POINTER  TO  CURRENT  SUFFER  LINE  */ 

OCL  I COUNT, R INDEX)  BIN  F I XEDI 15 .0)  I Hi  T I D)  ; 

K>  /*  /*  MARGIN  TABLE  ANS  PARAMETERS  FOR  PRINTING  AND  COMPUTING  MARGINS  */ 

DCL  MARGIN! 0: 15)  BIN  FIXED! 15.0) INITI 1 ) , 

IDELMARG  INIT12).  IMARGIN  INITI9),  NCOL  INITIBO))  BIN  FIXE0I13.0). 

PAGENO  CEC  F IXEDI 3,0)  INITI1); 

7*  /*  PUShDOWN  LISTS  s STACK1  * OPERATION,  STACK2  HAS  LABEL  IS ) , STACK3  * LlVEl  *7' 

DCL  ISTACK1  CHARI  5)  VAR,  STACK2 !3)  CHARI31 ) VAR,  STACK3  DEC  F1XED(2))  CONTROLLED; 

/*  /*  BO-COL  RECORDS  ARE  READ,  1 AT  A TIME.  INTO  NCARD.  EACH  STATEMENT,  AS  IT  IS  SEPARATED'  FROM  NCARD,  IS 
/*  STORED  IN'lTnE  FOR  ANALYSIS,"  TEMLINE  IS  WORKING  STRING  STORAGE  */ 

DCL  NCARD  VAR  CONTROLLED, 

LINE  VAR  CONTROLLED, 

TEMLINE  VAR  CONTROLLED; 

/*  /*  MISC,  VARIABLES  : FLAGS,  ETC.  */ 

CCL  ICOMFLG.TF.FL)  FIXED  BINU5.0!  INITIO), 

"Tmno  Chari  lol  VAR, 

INV1.NV2. NST.NEND.THISN.LASTN.PT)  BIN  FIXECI15.0); 

CCL  IFLAG.FIMS.LEVF  .QNFLAG.RFLAGI  a I T 1 1 » INITI'O*  B);  

/*  /*  CLEVEL  IS  CURRENT  LEVELS  PLEV  IS  SAVED  PRECEDING  LEVEL  USED  IN  SOME  ELSE  STATEMENTS  */ 

CCL  ICLEVEL.PLEV)  DEC  FIXEDI2)  INITIO): 

/*  /*  BINARY  CONSTANTS  */ 

DCL  I ZB"  INlTlOtr  ONEB  INI  Til) . TWJd  INITI2))  BIN  FlxEDliS.O): 

/*  /*  LOCK  FOR  CG  WEEK  COUNT  = BUFCGl.*20).  TeSTCG  * NUMBER  DEFINING  A CG  I ,*HALFCG,  WHICH  IS  BUFCG/2)  */ 
DCL  IBUFCG  INIT!20),HALFCG,  TESTC„  INI T! 71 1 BIN  FIXEDI15.0): 

/*  /*  CHCOOE  TABLETCPARATES  SklPCODE  INTO  FORE  AND  AFT  COMPONENTS  */ 

CCL  CHCOOE 1 0:9,2)  BIN  FI XEDI 13,0)  INITt  0,0,  1,0,  1,3,  0.3.  0.4,  0,3,  6,0,  6.4.  8,0,  8.4); 

/*  /*  STATEMENT  TYPES  */ 

DCL  LT  YP  E 1 7 ) CHAR  1 4 ) VARINlT  f'AST*.  *10'.  'CAL'.  'CTRL*.  'STOR*,  'ON',  'COM*): 

/*  /*  BREAK  CHARATERS  AND  NULL  ARRAY  */ 

DCL  BLANK  CHARU)  INITI*  •): 

DCL  BRKI8)  CH/RI2)  VAR  INIT  !•••*.  •!*,  •)•."•/*•,  •*/*,  •:•): 

DCL  MTLABI5 ) CHAR  I 2 ) VAR  INITI C5I • • » I 
/*  /*  INPUT  IS  SYSTEM  FILE,  CARDS, BOCOL.  PROVIDE  FOR  END  OF  FILE  */ 

/*  .." 

ON  ENDFILE  ISYSIN)  BEGIN; 

FINIS  - '1*b: 


1 

00000010 

1 

00000011 

1 

00000012 

1 

00000013 

1 

00000014 

1 

00000015 

X 

00000016 

1 

00000018 

*/ 

00000020 

*/ 

00000030 

*/ 

00000040 

*/ 

00000050 

*/ 

1 

OOOOD060T 

00000070 

2 

00000070 

2 

00000070 

2 

00000070 

2 

00000070 

2 

00000070 

2 

00000070 

2 

00000070 

*/ 

1 

ooooinw 

00000170 

*/ 

1 

00000180 

OOGOO2O0 

2 

00000200 

2 

00000200 

*/ 

1 

000002*0 

00000260 

+/ 

00000290 

*/ 

l 

00000290 ' 
00000330 

2 

00000330 

2 

00000330“ 

*/ 

1 

00000360 

00000370 

2 

00000370"' 

2 

00000370 

1 

00000410 

+/ 

1 

00000430 " 
00000460 

*/ 

I 

00000470 

00000480 

*/ 

1 

00000500 

00000530 

*/ 

1 

00000550 

00000570 

*/ 

1 

00000600 

00000610 

*/ 

1 

00000640 

00000650 

i 

00000660 

1 

00000680 

*/ 

*/ 

00000690 

1 

00000710 

1 

00000730 
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n 


t 

j 


i 


j 

GC  TO  ENDPD; 

/*  

END-: 

/♦  

/*  /*  READ  IN  LINESIZEI8D  JR  120)  FOR  OUTPUT.  MARGIN  PARAMETERS  */ 

/*  

ON  ENDFILE(CCIN)  begin: 

PUT_ED  IT ( 'NOT  ENOUGH  CONTROL  INFORMATION  SUPPLIED  (STS 004)  .'HA); 

PUT  ED.IT  ( 'ITEM  I:  LENGTH  OF  PRINTLINE:  SUGGESTED  120*  I C SKI  P(  I ) . A ) ; 

PUT  EOITI'ITEM  2:  BEGINNING  MARGIN : SUGGESTED  9 • ) I SK IP  1 1 ) , A ) : 

PUT  EDIT!  'ITEM  3:  MARGIN  STEP  SUE:  SUGGEST  5 • ) ( SKIP!  1 ) , A) : 

PUT  EDIT! 'ITEM  4:  tHE  NUMBER  20' ) I SKtPl 1 ) ,A) 5 
PUT  EOITI'ITEM  5:  THE  NUMBER  7*  MSK1PI 1 ) .A)  ; 

PUT  EOITI'ITEM  fa:  MAX  » CHARACTERS  PER  PL/I  STATEMENTS  SUGGESTED  800')  ISKlPIll.AI; 
POnOTTI^ITEM  7:  MAX  # EOITED  LINES  PER  PL/I  STATEMENT;  SUGGESTED  'll  • 50'  ) (SKIPIl ) ,AJ  ; 
PUT  EDIT! 'PROGRAM  TERM  INATED.  ' )(  SKI  Pll)  . A)  J 

/»  

SIGNAL  ERROR: 

/*  

end: 

/*  

OPEN  FILE (CCIN).FI LEI STSIN); 

GET  FILEiCCIN)  LI  ST I NCOL  « I MARGIN  tJcLMARG) ; 

/*  /*  OEf  iNE_o‘pneNS  i:aR  ■ outp ut~ rsv sprtn tf  *t 

OPEN  FILEISYSPRINT): 

/»  /♦  ACTION  AT  PAGE  END  ♦/  

ON  ENOPAGE  ISVSPRINT)  BEGINS 
S PAGENO  * PAGENC+lS 

PUT  FILE  ISVSPRINT)  PAGE"  EDIT  l 'PAGE  • , PAGENO)  ICQLINCOL-8)  , A.  Ft  311  5 
* END; 

/*  

TT-ff  T f t LT'F  I ft  5 T TFGT  *7  

PUT  FILEISYSPRINT)  EDIT! 'SOURCE  EOITED  BY  PLEOIT',  'PAGE  '♦PAGENO) 

ISKIPI2) .COL  l 10). A.COLINCOL-8) .A.FI3II ; 

PUT  SKIP12); 

/*  /*  INITIALIZE  PUSHDOWN  STACK  */ 

ALLOCATE  STACKl  INITI'TOP'). 

5TJTCk2r5 ) TMTT I f5l  • 'IT 

STACK3  INITIO); 

/*  /*  adjust  linelength  for  level  printout  */ 

IF  NCOL  - 80  THEN 
NCOL  * 72: 

ELSE  

NCOL  - lit: 

/*  /*  PARAMETERS  FOR  CG  SEARCH  */ 

GET  FILEICCIN)  LI STI BUFCG .TESTCG) ; 
hAL  FCG  * BUFCG/TWOB S 
IF  TESTC-G  > FALFCG  THEN 
DOS 

PIT  SKIP  LISTI'rtSCG  MUST  BE  < HALF  BUFCG'); 

STOP: 

ENOS  _____ 

GET  FILEICCIN)  LIST1STATEMENT_SIZE.MAX_LINES) S 
ALLOCATE  TEXT<MAX_LINESI , 

PR E F I X I K A X_L  I NE  S , 5 ) , 

LABEL!  HAX_LI  NES. 5) . 

TYPEIMAX_LINES) . 


I 00000740 

*/ 

l 00000750 

**/  00000760 

*/ 

1 00000780 
1 00000781 
1 00000782 
1 00000783 
1 00000784 
1 00000785 
1 00000786 
1 00000787 
1 00000789 
1 00000791 
......  */ 

1 00000792  ' 

♦/ 

1 00000793 
*7 

1 00000794 
1 00000795 
*/  00000796 

1 00000800 
*/  00000820 

~*r 

1 00000830 
1 00000850 
I 00000860 
1 00000880 

*/ 

*f  OOOUOB90 
1 00000900 
l 00000900 
I 00000930 
*/  00000940 

1 00000950 

2 00000950 
2 00000950 

*/  00000980 

1 00000990" 

2 00000990 
1 00001010 
2 00001010 

*/  00001020 

1 00001030 
1 00001040 
l 00001050 

3 00001050 
3 00001070 
3 00001090 
3 00001100 

*/  00001101 

1 00001102 

1 00001103 

2 00001103 
2 00001103 
2 00001103 
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-TO- 


SEU*!MAX_LINES) * 
LEVEL!  MAX_LINES>  . 
♦ SKIP(MAX.LINES) S 
TEXT*1 • ; 

PREFIX*1 * ; 

LABEL*1* : 

TYPE*1 • : 

'0.: 


SKIP3 
ALLOCATE 
ALLOCATE 


/*  /♦ 


TLINE  CHAR  ( STATE  MENTIS  I ZE  I 1 IM I T < 1 * I 5 
_NCA RO  CHARC STATEMENT.SI  ZEl  INITC1): 
ALLOCATE  LINE  CHAR! STATEHENT.SI ZE1  IMI Ti * * I S 
ALLOCATE  TEHL  INE  CHAR! STATEMENT. SI ZEI  IhIT!11); 
CREATE  MARGIN  TABLE  */ 


CALL  SMARG: 

/♦ 

/♦  /*  PART  II 


*/ 


/♦  ✓*  HERE  WE  START  EDITING,  1 STATEMENT  AT  A TIME 
/♦  /♦  UPDATE  POINTERS  AND  INDEX  */ 

GO:  COUNT  * COUNT ♦ONEBi 


RINDEX  * ADCPTR(R INDEX  I « 

L INDEX! COLNT ) * R INDEX, 

/*  /*  GET  1ST,  STORE  CONDITION  PRFIX  AND/OR  LABEL 
/♦ /♦  IF  EOF,  EMPTY  BUFFER  Al*D  END  *7 
CALL  REAO: 

/♦  


♦/ 


*/ 


*/ 


/♦  /♦  COPE  HERE  CN  ECF 
ENDRD:  IF  (FINIS)  TFEN 

IF  (-RFLAGI  THEN 


do; 

COUNT  * CCUNT-ONEB: 
RINDEX  * SliBPTR!  R INDEX • : 
GO  TO  ifcg; 


/♦ 


end; 


ELSE 


DO; 

PUT  SKIP  LIST! •♦♦MISSING  CARD(S)**'>; 
Go~  THIndprog; 


/* 


end; 


/♦  /♦  NOT  EOF.  ANALYZE  STATEMENT  FOR  TYPE,  GO  TO  TYPE  ROUTINES,  UPDATE  PUSHDOWN  LIST,  ASSIGN  LEVEL  AND 
/♦  SKlPCOOE,  STORE  IN  BUFFER  ♦/ 

/♦  /♦  IS  IT  COMMENT  ? */_ 

IF  COMFLG  * CNEB*THEN 
DO; 

call  comment; 


/* 


/♦ 


GO  TO  P3; 


end; 

/♦  /♦  NO,  UPDATE  STACKS 
CALL  PUSHPUL; 


*/ 


/♦ 


/♦  /♦  NULL  ST.  ? ♦/ 

IF  LENGTH(LINE) 
GO  TO  ce; 


ONEB  THEN 


/♦ 


2 

00001103 

2 

00001103 

2 

00001103 

1 

00001107 

1 

00001108 

1 

00001109 

1 

OOOOlilO 

1 

00001111 

1 

00001112 

1 

00001113 

1 

00001114 

1 

00001115 

1 

00001116 

♦/ 

00001117 

1 

00001120 

♦ / 

♦/ 

00001130 

*/ 

00001140 

♦/ 

00001150 

1 

00001160 

i 

OOOOU70 

l 

00001180 

♦/ 

00001190 

♦7 

00001200 

l 

00001210 

♦/ 

♦/ 

OO00122O 

i 

00001230 

2 

00001230 

4 

Ooool235 

4 

00001260 

4 

00001270 

4 

00001280* 

*/ 

4 

00001290 

2 

00001300 

4 

00001300 

4 

00001320 

4 

00001330 

*/ 

4 

00001340 

♦/ 

OO0O135O 

♦/ 

00001350 

♦ / 

00001390 

1 

00001400 

3 

00001400 

3 

00001420 

*/ 

3 

00001430 

♦ / 

3 

00001440 

*/ 

00001450 

1 

00001460 

*/ 

♦ / 

00001470 

1 

00001480 

2 

00001480 

*/ 


/♦  /♦  THFL  IS  CLUE  TO  TYPE  ♦/ 


*/ 


00001500 


Moo**  Butmett  In< 


r 


L 


ro 

-c- 

to 


— 
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/*  /*  COMPLETEO  ’ELSE  • ? */  */ 

IF  THFL  * TWQB  THEN  I 

GO  TO  f’:  2 

/♦  */ 

/*  /*  FOR  THFL  = 0 OR  2 */  */ 

/*  /*  IS  IT  PREPROCESSOR  STATEMENT  *!  */ 

IF  SUBSTS(L1NE,1. l>*'%'  THEN  1 

00:  3 

CCLNT=COUNT-l;  3 

GO  TO  TESTFN:  3 

/*  */ 

END : 3 

/*  r*  IS  IT  AN  • IF*  ? */  */ 

Cl:  CHND  = SLBSTR(LINE.1.3I J 1 

IF  (CM  NO  = 'IF  *)I(CMND  = • I F t • * I (CMNO  * 'IF**')  THEN  1 

CALL  if:  2 

/*  */ 

/*  /*  IS  IT  DO.  PROC.  BEGIN  JR  ENTRY  ? */  */ 

C2:  CMNO*  SU8STR(LINE.l,6) : 1 

IFICMND  = 'ENTRY  • I I ICMNO  * * BEGIN  *)l  (CMNJ  = • ENTRY ; • I I ( CMND  = *)£GIN:*)  THFN  1 

GO  TO  YESBL:  2 

/*  */ 

CMNO  * SUBSTRILINE.1.3) J 1 

IF  (CMND  = *00;* IKCMND  = *00  • ) THEN  1 

GO  TO  YESBL:  2 

/*  . */ 

CMND  = SLBSTRILINE.1.5) ; 1 

IF  (CMND  = 'PPOC: • ) I (CMND  = *PR3C  *)l  (CMND  = *PROC(*»  THEN  l 

GO  TO  YESBL:  2 

/*  */ 

CMND  * SUBSTR ( LINE. 1 . 10)  ; 1 

IF  (CMNO  -=  'PROCEDURE  •»  6 (CMND  -=  • PROCEDURE  • ' ) & (CMNO  -.=  • PROC  EDURS  ( • I THEN  ’ l 

GO  TO  CC2:  2 

/*  */ 

/*_/*  IT  IS  A BLOCK  COMMAND  */  */ 

YESBL:  CALL  BLOCK(CI*NC):  1 

/*  */ 

GO  TO  P3 : l 

7T-,T7..7m.... ♦/ 

/*  /*  TRY  FOR  'END'  */  */ 

CC2 : CMNO  * SLBSTR (LINE. 1. A) : l 

IF(CMND  -=  'END  *)l(CMNO  = 'END:')  THEN  1 

00;  3 

CALL  PENO;  3 

7*  .77......... */ 

GO  TO  P3:  3 

/*  */ 

End:  ' * 3 

/*  /*  IS  IT  A CONTROL  STATEMENT  7 */  */ 

C4:  CMNO  * SUBSTRI LINE. 1.5) : 1 

IF(CMND  * 'CALL  •>  THEN  1 

DO:  3 

CALL  CTRLC:  • 3 

/*  */ 

GO  TO  P3:  3 

/* */ 

END:  " " 3 

IF(CMNO  = 'GOTO  •)  THEN  1 

GO  TO  C4l: 2 

* - - ’■  * * > 

— 


5 • J _ _ ...  t . r 

PAGE  5 

[”]  IF(CMNO  * ‘WAIT  • 1 1 ( C MNO  * 'WAlTj'il  ( CMNO  * ‘STOP  MKCMNO  = 'STOP;'Jl  ( CMND  = ‘EXIT  Ml  (CMND  = 1 00001980 

* EXIT; • I THEN  1 00001980 

GO  TO  CAA:  - 2 00001980 

/«  */ 

CMND  = SUBS TR ( L IN E • 1 • 6 I ; 1 00002020 

IFICKND  * ' OELAY  MKCMNO  = * DELAY  : M THEN  1 00002030 

GO  TO  CAA:  2 00002030 

IF  (CMND  * 'GO  TO  •)  THEN  1 00002050 

CAl:  OC:  ' 3 00002050 

CALL  CTRLG;  3 000020T0 

/* .. */ 

CO  fa  P3:  - 3 00002080 

/♦  */ 

END:  3 00002090 

CMNO  * SUBSTR(LiNE.l.7l : .....  x 00002100 

IF  (CMNO  = 'RETURN  Ml  (CMNO  - 'RETURN: M THEN  1 00002110 

CAA: DO:  _ 3 00002110 

CALL  CTRLOJ  ' >3  00002130 

/* */ 

GO  TO  P3;  3 000021A0 

/*  - */ 

end:  3 00002150 

/*  /*  NOT  CONTROL  ST  */  */  00002160 

/*  /*  IS  IT  10  ? */  ""  - - - “ */  060O2ffO 

C5:  CMNO*  SUBSTRILINE.l.AI J 1 00002180 

I F ( CMN D = 'GET  MKCMNO  * 'PUT  •»  THEN  1 00002190 

GO  fO  055:'“  " * '*  “ - - - - - 2 o0qo21^0 

^ /*  */ 

nh  CMNO  = SUBSTRILINE.1.5I : 1 00002210 

IF( CMNO  * 'OPEN  MKCMNO  * 'READ  • » THEN  " " 1 00062220- 

GO  TO  C55:  2 00002220 

/*  */ 

CMND  * SC BSTR ( lT N E.*n 6)  : * " 1 000022A0 

IF  (CMNO  * 'CLOSE  MKCMNO  = 'WRITE  M THEN  l 00002250 

GO  TO  C5  5: • 2 00002250 

CMNO**  SUBSTR (LINE* 1 • 7 1 • l 00002270 

IF(  CMND  * 'DELETE  MKCMNO  * 'LOCATE  Ml  (CMND  = • FCRMAT  M I (CMND  = • FORMAT!  M THEN  l 00002280 

GO  TO  C55:  " ' - - - 2 00002280 

/*  */ 

CMNO  * SUBSTR  (LINE.  1. 8)  5 _ _ l 00002320 

I F( CMNO  - 'REWRITE  'I  I (CMND  = 'DISPLAY  M THEN  1 00002330 

C55 : DO:  3 00002330 

CALL  10 SUB:  3 00002360 

/*  */ 

GO  TO  P3:  3 00002370 

/*  */ 

END":  “ * 3 00002380 

/*  /*  IS  IT  OECLARAT ICN  ? */  */  00002390 

C6:  I F ( SUBSTR  (LINE.  1 .A)  = 'OCL  Ml  ( SUBSTR  (LlNE.l  .8  I = 'DEFAULT  Ml  ( SUBSTR  ( L INE  . 1 . 8 » = 'DECLARE  Ml  1 O0OO2A0O 

(SU6sTft(LINE,i; 91— *" tSllCCSTE'  M ThEN ...  t 00002400 

00:  3 00002AOO 

CALL  DECLARE:  3 00002A50 

7*  .•••'«•••• */ 

GO  TO  P3:  3 00002A60 

/*  */ 

_ — -gfio; — -•  3 00002A70 

I F I SUBSTR(L INE. 1.5)  = 'FREE  M THEN  i 00002A80 

GO  TO  C8:  2 00002A80 


— ’ — 


r 


/*  /♦  IS  IT  ON  • SIGNAL • REVERT  ? 
CT:  IF  (.SUB  ST  R(LINE,l#3>  * 

do; 

CALL  ON  SUB: 


♦/ 
•ON  • ) I 


Ptr,  f 

(SJd^TK(LlNc«1.7l  * ‘SIGNAL  Ml  UUBSTR  ( L IN?  , 1 . 7 I = ‘REVERT  «)  THEN 


/* 

/♦ 


GO  TO  P 3: 


*/ 


ro 

-C? 

-t=- 


end; 

/♦  /♦  NONE  OF  'PRECEDING*  CLASS  IT  ASSIGNMENT 

C8s_  call  assign: 

/*  . 

/*  /*  PART  III  ♦/ 

/♦  /♦  RETURNED  FROM  TYPE  SUBS#  NOW  CHECK  F JR  OUTPUT  * CG * ETC.  TETURN  TO  • G0‘ 
'/♦PROGRAM  TF  FINISHED.  */' 

P3:  THFL  * ZB: 

/♦  /♦  POINTER  TO  FIRST  BUFFER  LINE  OF  CURRENT  STATEMENT  ♦/ 

THISN  * LINDE XC COUNT ) : 

NV1  * SKIP(THISN) : 

/♦  /♦  IF  THIS  IS  VERY  FIRST  ST.  DC  ANY  PRE-SKIP  ♦/ 


IF  INPUT  REMAINS.  OR  TO  END 


TFTCOUNT  > li  THEN 
GO  TC  MORNl; 


/♦ 


NV2~ * CHCOOEiKVi.ONED) ; 

IF  NV2  * ZB  THEN 

GO  TO  TESTFN: 

IFCNV2  * CNEB  I f < NV2*6FI  C NV2  « 81  THEN 
CALL  OLIFSTCNV21: 


/♦ 


7*~7*  SUBTRACT  PRE-3K IP~P RIWCUBI *7~ 

SKIP(THISN)  * CHCODEC  NV1 . TWOBI : 
GO  TO  TESTFN: 


/* 


/♦  /♦  NOT  LINE  I:  PTR  TO  LAST  LINE  FO  PRECEDING  ST 
MORN1 : LASTN  * SUBPTRf THI SN)  ; 


*/ 


NV2  * SKIP!  LASTN) 
/♦  /*  RULE1  : FLAG  OUTPUT 
RUL El:  IF(LEVELCTHISN)  * 

LFvF 


IF  CHANGE  IN  LEVEL 
LEVEL! LASTN) I THEN 

•0*6: 

ELSE 

LEVF  * *1‘b; 

/♦  /♦  RULE2  • EXAMINE  CURRENT  ST.  FOR  PRESMP. 
RULE2:  IFCnVI  * CNEB 1 1 1 N VI  * TWOB)  THEN 

IFCNV2  * A ) I ( NV2  * 5)  THEN 
SKIPCTASTN) 


*/ 


IF  FOUND.  ADO  fO  PREV.  ST,  SUBTRACT  HERE  */ 


ELSE 


SKI  PC  LA  STN ) 


5: 

3: 


ELSE 


IFCNVI  = 6IICNVI  * 71 
_ SKIP!  LA  STN)  * 5: 


THEN 


ELSE 


IFCNVI  = 8)  ICNV1  * 9)  THEN 
IFCNV2  * ZB)  THEN 


ELSE 


IFCNV2  * 3)  THEN 
IfKlPTLAlTnl 


5; 


SKIP C THI SN ) * CHCOOECSKIPCTHISN) .TrOBI : 
/♦  /♦  RULE3  D IMPLEMENT  SKIPS  FOR  PRECEDING  ST 


*/ 


r 

tijr-:;' 





♦/ 

♦/ 

00002503 

1 

00002510 

3 

00002510 

3 

00002550 

♦ / 

3 

00002560 

*/ 

3 

00002570 

♦/ 

00002580 

l 

00002590 

*/ 

♦/ 

00002600 

♦/ 

00002610 

♦/ 

00002610 

1 

00002650 

♦/ 

00002660 

1 

00002680 

l 

00002690 

♦/ 

00002700 

I 

00002720 

2 

00002720 

♦/ 

I 

00002740 

1 

00002750 

2 

00002750 

1 

00002770 

2 

00002770 

♦/ 

♦/ 

00002790 

1 

00002800 

1 

00002810 

*/ 

♦/ 

00002820 

l 

00002830 

1 

00002840 

♦/ 

00002850 

l 

00002860 

2 

00002860 

i 

00002880 

2 

00002880 

♦/ 

00002900 

1 

00002920 

2 

00002920 

3 

00002920 

2 

00002950 

3 

00002950 

1 

00002970 

2 

00002970 

3 

00002970 

2 

00003000 

3 

00003000 

4 

00003000 

5 

00003000 

4 

00003040 

5 

00003040 

6 

00003040 

1 

00003070 

♦ / 

00003080 

1 





- 


r 
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/*  /*  ALSO  OUTPUT  IF  LEVEL  CHANGE  (RULEll 
RUL_E3.L  NV2  * SKIP(LASTN): 

IF(LEVF)  ICNV2  ^.=  IB)  THEN 
DC: 

CALL  OUTPUTCCOLNT-ONEBI 5 
CALL  M0VUP(C0UNT-0NE8> ; 


*/ 


7 

+ / 


/* 


GO  TO  TESTFN; 


/* 


END  : 

/*  /*  NO  OUTPUT  YET  • LOOK  FOR  CGIF  BUFFER  = BUFCG  OR  IF  JEOF  AND  BUFFER  > HAL  FCG ) • 
IFCG:  IF  (COUNT  * BUFCG)  I V I COUNT  >*  HALFCul  & FINIS]  THEN 

GO  TO  RLLE4; 


1 

l 

3 

3 

3 

*/ 

3 

*7 

3 


00003090 

00003110 

00003120 

00003120 

00003140 

00003150 


00003160 


*/ 


*/ 


1 

2 

*/ 


00003170 

00003180 

00003210 

00003210 


ho 

-Cr 


/*  /*  NOT  FULL  ENOUGH  * READ  MORE  UNLESS  NO  MOKc  INPUT 
TESTFN:  IFI-.FINISJ  TFEN 
GO  TO  GO; 


*7 


*/ 


/* 


1 

2 

♦ / 


00003240 

00003260 

00003260 


/*  /*  EMPTY  BUFFER  AT  END  */ 
OUT  END:  CALL  OUTPUT ( COUNT  > 5 


*/ 


/♦ 


GO  TO  endprog: 


/* 


1 

*/ 

1 

*/ 


00003280 

00003290 


00003300 


/♦  /*  SEARCH  FOR  C G */ 

RULE4:  IF(FINIS)  TFEN 

CALL  CGEKOf NST«NEND) • 


*/ 


ELSE 


CALL  CGFINDI NST.NENDI ; 


JJ1_ 


/* 


/*  /*  NOT  FOUND.  OUTPUT  HALF  BUFFER  TOR  At.  L • IF  ENO  OF  OAT  AT 
I F ( N ST  * ZB)  THEN 

ififinisi  then 

GC  TO  OUTEND; 

ELSE 

DO  : 

CALL  OUTPUT I HALFCGI « 

CALL  movup(halfcg) : 


*7 


1 

2 

1 

2 

*/ 


00003310 

00003320 

00003320 

00003340 

00003340 


- 1 


/* 


GO  TO  go: 


/* 


end: 


1 

2 
"3 
2 
4 
4 
4 

*/ 

4 

*/ 

4 


00003350 

00003380 

00003380 

00003310 

00003410 

00003410 

00005430 

00003440 


00003450 


/*  /*  FOUNOCG.  OUTPUT  PRE-CG  LINES 
IFINST  = CNEB)  THEN 
GO  TO  CGQUT: 


*/ 


~T*~ 


PT  = SUBPTR ( L INDEX! NST I ) : 
SKIPIPT)  = 3: 

nsT^one'b:" 


1 

2 

*/ 

1 

1 


00003460 

00003470 

00003480 

00003480 


00003500 

00003510 


NST 

CALL  OUTPUT (N  ST  ! : 
CALL  MOVUP! NST I ; 


l 00003520 


1 

1 

*/ 


00003530 

00003540 


/*  /*  OUTPUT  CG  */ 

NEND  * NEND-NST: 


♦ / 


CGOUT : 


/* 


IF(NEND  * COUNT  I THEN 
GO  TO  OUTGP; 


OUT  GP: 


PT  *~TUBT>TRTLlNDEXTfaENtf*ONEBn  : 
SK  IP  ( P T ) * 2: 

CALL  OUTPUT ! NENDI  : 


1 

2 

♦ / 
1 
1 


00003550 
1 00003560 
00003570 
00003570 


00003590 

00003600 


1 00003610 


PAGE 
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PO 

Xr 

cn 


/♦  # #( 

CALL  MOVUP(AEND); 

1 

*/ 

00003620 

GO  TO  testfn: 

1 

00003630 

/*  «_•, 

*/ 

/*  /♦ 

ALL  INPUT  PROCESSED,  ALL  OUTPUT  D J.Nc  . TELL  IT.  */ 

*/ 

00003640 

ENDPROG: PUT  PAGE  LIST  (***PL£OIT  FINISHED***); 

1 

00003660 

/*  /* 

********  page  ?o  ON  HANDWRITTEN  SHEET i ********  */ 

*/ 

00003680 

/*  /* 

SUBROUTINE  READ  GETS  INPUT  AND  9EG»NS  T 3 PROCESS  STATEMENT  */ 

*/ 

00003710 

REAC: 

proc: 

2 

00003730 

/*  /* 

GETSTAT  PUTS  STATEMENT  INTO  LINE  */ 

*/ 

00003740 

CALL  GETSTAT! 

2 

00003750 

/* 

*/ 

/*  /* 

CCMMENTS  ARE  NOT  PARSEO  */ 

*/ 

00003760 

IF  (CORF LG  = ONEB)  THEN 

2 

00003770 

RETURN*. 

3 

00003770 

/*  /♦ 

RL ABEL  SEPARATES  LABEL ( S ) AND  CONDITION  PREFIX(ES)  */ 

*/ 

# 

00003790 

CALL  RLAbEL: 

2 

00003810 

/*  > • 1 

-■ 

*/ 

/*  / + 

NOV,  RETURN  IS  FADE  TO  PLEOIT  */ 

♦/ 

00003820 

END  REAC : 

2 

00003830 

GETSTAT:  proc: 

2 

00003840 

OCL  CL A6L<  0*  21  LABEL  I Nl T( I SI TC *CJMT  «H0C0'4T ) * 

2 

00003850 

i NUbOT  « NCJM ) BIT<11  iNlTC'O'aJ. 

3 

00003850 

KCF  CHAR(l)* 

3 

00003850  ' 

KCC  CHAR( 2 1 * 

3 

00003850 

KS  BIN  FIXED! 15.01 i 

3 

00003850 

COMFLG  = lb: 

2 

00003900 

/*  /* 

IF  MORE  TEXT  NEEDED • READ  NEk  RECORD  */ 

*/ 

00003910 

IF  ! NCARC  * f,l  THEN 

2 

00003920 

GU~ 

DO  ; 

4 

00003920 

RFLAb  * •C,B; 

4 

00003940 

CALL  IN; 

4 

00003950 

7*  ................................................................................ 

END  Gl : 

/*  /*  SUBROUTINE  IN  READS  SYSIN  (SYSTEM  FILE)  */ 

IN: PRCC! 

/*  /*  READ  CARD  COL 2 - 72.  APPEND  TO  NCARD  */ 

/*  /*  ON  EOF.  FINIS  = l AND  RETURN  MADE  TJ  ENDRJ  (IN  PLEOIT)*/ 

AG  TNI  - GET  FIlE(SYSIN)  EOlT(COMr_CHAft. LINE)  ( A (I ) , A(79)  ) 5 

if  ncard*"  then 

SE  UNO=  SUBSTRI L INE . 72 ) 5 
LINE  * SU3STR(LlNE.1.7l) : 
tF  CON  T_CHAR= • t • THEN 
DO; 

CALL  OUTPUT! COUNT- JNE6) : 

CALL  MOVUP(COJ.mT-L'imEB) S 

/*  

PUT  EOlTlLTNEi  ( SiU  P(  1 ) .X  ( I ) . A ) ; 

GET  FILE! SYS  IN)  EUlT(COiMT_CHAR,LINE)  ( A(  l ) , A(  79  > ) ; 
LINE-SUBSTR(LI.NE.1  .71)  ; 

DO  HHI LE(CONT_CHAR-»® ' t ' ) : 

PUT  EDIT(LIME) (SKIP(1).X(1),A); 

GET  FILE(SYalN)  EDI T ( CONT.CHAR.L INE ) (A(1I,A(79)) 

LTNE*SuBSfR(LI ME.l ,71 ) ; 

end; 

PUT  EDIT(LINE)  (SKIP(l) . X ( 1 ) .A) • 

GO  TO  AGIN: 

/*  

end; 


..  */ 

4 00003960 
*/  00003970 

3 00003980 
*/  00003990 

*/  00004000 

3 00004010 

3 00004013 

4 00004013 
3 OOOO4030 
3 00004031 

5 00004031 
5 00004032 
5 00004033 

..  *> 

5 00004034 
5 00004035 

5 00004037 

6 00004038 
6 00004039 
6 00004040 
6 00004042 
6 00004043 
5 00004044 
5 0000404? 

..  */ 

5 00004046 


Moof*  Suv 


. r «*  cr 

_*  9 » . «• 

PAGF  9 

IF  LINE*’  • THEN  3 00004047 

G<3  TO  AGIN:  4 00004047 

/*  */ 

DO  1*71  TO  1 3Y  -1  -HlLcISJBSTRILINc.I,  1)  = ' •);  4 00004048 

END;  4 00004049 

IF  K71  THEN  3 00004050 

I*  1*15  4 00004050 

LINE*SUBSTRILINE,1.II : 300004051 

DO  1*1  TO  71  WHILEISUBSTRILINE.I.I)*'  4 00004052 

End;  4 00004053 

IF  I>1  THEN  3 00004054 

1*1-1 ; 4 00004054 

L IN E*SUSSTR ( L INE • 1 1 ; 3 00004055 

t*LENGTH(.NCARD)*LENGTH(4.1N£)  ; 3 00004056 

IF  I>STATEMENT_SUE  THEN  3 00004057 

DO;  5 00004057 

PUT  EDIT{  ‘STATeMENT  SUE  EXCEEOEO.  * ) I PAGE.  A) ; 5 00004058 

PUT  EDIT!'  NCARu:  • .NCARD) I SKI  PI 1» .2  A) $ 5 00004059 

PUT  EDIT!*  LINE:  • .LINE) (SKIP! 1 1 . 2 A):  5 00004060 

STOP;  __  _ 5 00004061 

ENO;  - - 5 00004(562 

NCARD  * NCARD  II  LINE;  3 00004063 

ENO  IN:  3 00004064 

/*  /*  BRANCH  for  TESTICOMFLG  * 0».  COMMENT (II.  N0I2)  +/  *t  00004065 

Cl:  GO  TO  CLABLI COMFLG)  : 2 00004070 

/*  */ 

/*/*  DELETE  LEADING  BLANKS  */  ” " " " *T  00004080 

ro  /*  /*  IS  IT  COMMENT  ? ♦/  */  00004090 

^ ISITC:  NCARD*  SUBS TR( NCARD .VERIFY! 4c ARO. BLANK  1 ) : 2 00004100 

i f index (NCARD. brk( 6 > » = i then  - - - - 2~ 00OD4IIO 

do:  4 00004110 

COMFLG  * 0NE8:  4 00004130 

GO  TO  COMT:  " ‘ - - 4 00004140' 

/*  ♦/ 

end:  4 00004150 

'/*/*  STATEMENT  1 5 NOT  COMMENT.  MILL  END  I H SEMICOLON  I NOT  IN  QUOTES  OR  COMMENT)  */  */  00004160 

COMFLG  * TWOS:  2 00004190 

NOCOMT:  DC  KS  = l TO  LENGTH! NCARD) ; 3 00004200 

'kch*Substr(ncard.ks.ii : ' 3 oooo42lo 

IF(KCH  = BRK(  3 ) ) C ( -»NQUJT)  u I-.MCOM)  THEN  3 00004220 

GO  TO  FBRK:  4 00004220 

IF  (KCH  * BRK(D)  THEN  " 3 00004250 

NQUOT  * -.NOUOT:  4 00004250 

ELSE  3 00004270 

IF  KS-»=LENGTH(NCARJ)  THEN  - - 4 00004270 

IF  ( SUBSTR(NCARD.KS.2)=BRK(6)  I SU BSTRI NCARD. K S, 2 )= 8RK ( 7 ) I THEN  5 00004270 

NCOM  * -.NCUM:  6 00004270 

END  NOCOMT:  ' » 3 00004310 

/*  /*  NO  ENOBREAK  FCLND.  GET  MORE  TEXT  */  */  00004320 

MORE:  RFLAG  * ‘l'B;  2 00004330 

CALL  IN:  " 2 00004340 

/*  

GO  TO  Cl:  2 00004350 

/*  . .......... ..... . .^r.~. ...  ............... .........  ...................  . */ 

/*  /*  FOUNO  ENOBREAK.  STORE  ST.  IN  LINE  */  */  00004360 

FBRK:  LINE  * SUBSTRI NCARO 1 1 »KS ) ; 2 00004370 

/*”/*  CLTaR- ST. 'FCftM 'NCARD  " */  */  00004380 

NCARD  * SUBSTRI NCARO »KS+1 ) : 2 00004390 

RETURN:  2 00004400 


Moo>*  Bovn*»»  cp"M.  Irw- 
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f-’  /*  /*  COMMENT  ST..  FIND  END  */ 

COHT ; DO  KS  * 3 TO  LENGTH1NC ARJI  - 1; 

KCC  = SU6STRI NC ARD » KS, 2 1 ; 

IF  I KCC  * BRKI7))  THEN 

DO! 

KS  * KS  ♦ i; 

GO  TC  FBRK: 

/*  

END  COMT; 

/*  /*  NO  ENO  BREAK  FOUND  */ 

GO  TC  MCRE: 

7*  7T7T...;... 

END  GETSTAT; 

/*  /*  RLABEL  IS  CALLED  BY  PLEDIT,  IF  AND  ELSc  TO  SEPARATE  ALL  PREFIXES  */ 
RLABEL:  proc; 

DCL  (KLA.NLAB  INIT  (01)  BIN  FIXED! 15,01. 

KF  CHAR; 

/*  /*  UP  TO  31  CHAR  IN  A PREFIX  •/ 

/*  /*  FIND  ANY  CONDITION  PREFIXIESI  */ 

CALL  SPREFX: 

/* 

SPREFX;  PRCC: 

DCL  (IP.NP  INITIOII  BIN  FIXED  <1?.DI: 

/*  /*  SET  PREFIX  ARRAY  TO  NULL  ♦ / 

PREFIXI R INDEX. *1  * MTLAd; 

IS  I TP ; NP  = NP«-ONEB; 

L INE  - SUBSTRl L1NE,V£RIFY!lINL, BLANK) I : 

^ IF  SUBSTR!LINE.1.1)-*3RMA>  THEN 

OO  RETURN: 

/*  f*  FOUND  PREFIX  START.  LOOK  FOR  END  */ 

LPP:  DO  IP  * 2 TO  LENGTHILINE)  - l; 

. IF  SUBSTRILINE.IP.2I  THEN 

GO  TO  DEND; 

/*  

PREFIXIRINDEX.NPl  * SUBaTRl L I NE.l , I P ♦ 1); 

LINE  * SUB StR (LINE. IP  ♦ 215 
/*  /*  REPEAT  FOR  ANOTHER  */ 

IF  NP  < 5 THEN 

GO  TC  I SI  TP : 

ELSE 

J return; 

DEND:  END  LPP: 

/*  /*  NO  END.  ERROR.  TRY  TO  GO  ON  */ 

PLT  SKIP  LISTI  '^UNBALANCED  PARENS  IN  PREFIX**'); 

IP  * IN DEXILINE.BR MB)  I ; 

IF  IP  = 0 THEN 
STOP.' 

PREFIX!  RINDEX.NP)  * SUBSTrU L I Nc , 1 , I P ) ; 

LINE  > SUBSTR! L INE* I P * I): 

if  np  < 5 then 

GO  TO  I SI  TP : 

/*  

END  SPREFX: 

/*  /*  LCOK  FOR  LTBELTST.  COLON 'POST  COME  BEFORE  BLANK,  OUCTE  OR  LEFT  PAREN  */ 
L AB EL! R INDEX,*)  * MTLAB: 

/*  /*  ALWAYS  DELETE  LEADING  BLANKS  */ 

RL1 s LINE*  SUBSTrILINE. VERIFyTLI Nt .BLaIK) ) ; 

NLAB  * SLAB  * 1; 

RLP: DO  KLA  * 1 TO  LENGTH!  L I.Nt:  J - I : _ 


10 


*/ 

00004410 

3 

00004420 

3 

00004430 

3 

00004440 

5 

00004440 

5 

00004460 

5 

00004470 

*/ 

3 

00004480 

*/ 

00004490 

2 

00004500 

♦ / 

2 

00004510 

*/ 

00004520 

2 

00004540 

2 

00004550 

3 

00004550 

*/ 

00004570 

*/ 

00004580 

2 

00004590 

*/ 

3 

00004600 

3 

00004610 

*/ 

00004620 

3 

00004630 

3 

00004640 

3 

00004650 

3 

00004660 

4 

00004660 

*/ 

00004680 

4 

00004690 

4 

00004700 

5 

00004700 

*/ 

4 

00004720 

4 

00004730 

*/ 

00004740 

4 

00004750 

5 

00004750 

4 

00004770 

5 

00004770 

4 

00004780 

*/ 

00004790 

3 

00004800 

3 

00004820 

3 

00004830 

4 

00004830 

3 

00004850 

3 

00004860 

3 

00004870 

4 

00004870 

*/ 

3 

00004890 

*/ 

00004900 

2 

00004920 

*/ 

00004930 

2 

00004940 

2 

00004950 

3 

00004960 
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KH  = SUBSTR(LINE,KLA,1 I; 

IF  (<H  * BRK(l))  I (KH  = BlANK)  I (KH  = BRM4))  THEN 
RETURN; 

IF  KH  = 6RK  ( 3 ) THEN 
00; 

L ABEL ( ft I NDEX ,NlAB)  = SUdSTR C L INE, 1 ,KLA ) ; 
LINE  = SUBSTR(HNfc,KLA  + l)  ; 

IF  NLAB  < 5 THcN 
'GO  TO  RL1; 


_ end; 

END  RLP; 

END  rlabel; 

/•  /*  FUNCTION  AODPTR  AND  SUBPTR  ARE  CALLED  TU  FIND  POINTER  TO  NEXT  (PRECEDING)  LINE 
/*~IS  SET  tO  50  */ 

AODPTR:  PRUC  ( PT ) RETURNS  (BIN  F I XED( 1 6 ,01 ) ; 

/*  /»  INCREMENT  BUFFER  POINTER^  ♦ / 

DCL (PNEXT » PT ) B I N F I X ED (15*0) : 

PNEXT  * PT  f ONES; 

IF  PNEXT  > MAX_LINES  THEN 
P N E > T * ONEB; 

RETURN  (PNEXT); 

END  ADCPTR; 

SUBPTR:  PROC(PT)  RETURNS  (BIN  FIXED? 1 3 * 0 ) I; 

/*  /*  FINDS  POINTER  TO  PRECEDING  BUFFER  LI.«E  ♦/ 

DCL  PT  BIN  F IXED( 15*0); 

IF  (PT  - ONEB) > ZB  THEN 
^ RETURN  (PT  - ONEB)  ; 

£ ELSE, 

RETURN! MAX.LINES1; 

END  SUBPTR; 

/♦  /*  ASSIGNMENT  STATEMENTS,  FREF  ST.,  ETC.  */ 

ASSIGN:  PROC:' 

/♦  /*  ARRIVES  HERE  BY  FALLING  THROUGH  ALL  OTHER  CLASSIFICATION  TESTS  OR  AS  •FREE*  ST. 
IF(LENGTH(LINE)<6)  I (SUBSTR(LiNfc,l,5)  1 FREE  •)  THEN 

TYPE ( RlNOEXl  - LTYPtCni 

ELSE 

TYPE (RI NDSX)  * LTYPE (51: 

SK IP (R INDEX)  = 0: 

LEVEL(RINDEX)  = CLEVEL: 

CALL  STEXT( L INE ) : 

/♦  

END  ASSIGN; 

/*  /*  PROCEDURE  FOR  BEGIN *00*  ENTRY,  PRQC  STATEMENTS  */ 

BLOCK:  PROC  ( CMNDi ; 

DCL  CMNC  CHAR( * ) VARYING: 

/*  /*  ENTRY  SKIPS  LINE.  NO  LEVEL  CHANGE  */ 

If TCMND-* ' 

do: 

SKIP(RINDEX)  * 1; 


ELSE 

END; 

00  i 

SK  IP( R INDEX  I = 0; 

FLAG  * •l’B: 

End: 

/*  /*  ENTER  IN  STACK  WITH  LABEL! S ) */ 

CALL  PLSFDON  (CMND , L ABEL ( RI NDcX , * ) ) : 


IN  BUFFER 


*/ 


BUFFER  SIZE 


3 00004970 

3 00004980 

4 00004980 
3 00005310 

5 00005010 
5 00005030 
5 00005050 

5 00005060 

6 00005060 
..  */ 

5 00005080 
3 00005090 
2 00005100 
*/  00005110 

*/  00005110 

2 00005140 
*/  00005150 

2 00005160 
2 00005170 

2 00005180 

3 00005180 
2 00005260 
2 00005270 
2 00005280 

*/  00005290 

2 00005300 

2 DbobSiio" 

3 00005310 

2 00005330 

3 00005330 
2 00005350 

*/  00005360 

2 00005370 
*/  00005380 

2 00005400 

3 D0DU5*0d 

2 00005430 

3 00005430 
2 OO00545O 
2 00005460 
2 00005470 

..  */ 

2 00005480 
*/  00005490 

2 00005510 
2 00005520 
*/  00005530 

2 00005540 

4 00005540 
4 00005560 
4 00005570 
4 00005580 
2 00005590 
4 00005590 
4 00005610 
4 00005620 
4 00005630 

*/  00005640 

2 00005650 


M©o»f  i\  ,ryi 


r 


PAG*  1? 


/* 


T YPE(R INDEX)  - LTYPEC4) ; 
LEvELCRINDEX)  * CLEVEL: 
CALL  STEXT( L INE I • 


END  BLOCK; 

/*  /*  THIS  ROUTINE  STORES  COMMENT  STATEMENTS 
COMMENT:  PROC; 

TYPECR INDEX ) * LTYPE(7I; 

/*  /*  ALL  COMMENTS  ARE  LEVEL  0 */ 

L EVELi R I NDEX ) = 0; 

““  IF  (COUNT  = 1)  THEN 
GC  TO  C SKIP ; 


*/ 


*/ 


~7*  ~7*  group  comments,  space  before  “first  and  after  last 

IF  TYPECLINDEX(COUNT-CNEbl)  -=  LTYPEC  7 1 THEN 
DO  : 

PT  = SUBPTR ( RINDE  X I ; 

IF  i SKI  PI PT)  * TWOdl  THEN 
SKIP  CPT)  * ONE a; 

ELSE 

SKIP  CPT)  = L*i 
SK  I PC  RINDE  X ) = 3: 

END; 


*/ 


*/ 


ro 

ui 

o 


ELSE 

CSKIP:  SKIPCRINDEX) 

CALL  STE  XTC  LINE  I ; 
/*  


TWOB: 


END  COMMENT; 


/* 

CGF 


/*  CGFIND 
IND: 


BIN  FIXEOC 15.0). 


/*  /* 


/* 

/* 


C OR  CCEND  I SEARCHES  BUFFER  FOR  CONCEPTUAL  GROUPS  */ 
PROC  CNST.NEND) ; 

DCL  (LCT ( 3 ) • LT.KC * JC .L2END. TcNU.JEND) 

STY  PE  CHARC4  ) VAR. 

FT  V PE  CHAR  C A ) VAR  INIT  <••); 

consider  each  gfoup  of  halfcg  statements t starting 
-1  IS  HIT.  if  Te'STCG  STATEMENTS  of  a GROUP  are  of  one 
FIRST  CG  ST..  NENO  = » OF  LAST  CG  ST.  */ 

JEND  = HALFCG; 

TEND  = COUNT  - ONES: 


*/ 


AT  TCP  OF  BUFFER 
TYPE  (ASSIGNMENT 


AND  CONTINUING 
, 10.  OR  CALL ) * 


UNTIL  BUFFER 
RETURN  NST  * 


BOTTOM 
U OF 


*/ 

2 

2 

2 

*/ 

2 

2 

2 

2 

2 

3 

*/ 

2 

4 
4 

4 

5 

4 

5 
4 
4 
2 
3 
2 

♦ / 
2 

2 

2 

3 

3 


*/ 

*/ 

♦/ 


00005640 

00005670 

00005680 

00005690 

00005700 

00005710 

00005720 

00005730 

00005740 

00005750 

00005750 

00005760 

00005780 

00005780 

00005810 

00005820 

00005820 

00005840 

00005840 

00005860 

00005870 

00005880 

00005880 

00005900 

00005910 

00005920 

00005940 

00005950 

00005950 

00005950 

00005990 

00005990 

00005990 

00006070 

00006080 


LO: 

NST  .NENO  s i B ; 

2 

00006090 

Li: 

DC  JC  = ONES  TC  JEND; 

3 

00006100 

LCT  = ZB: 

3 

00006110 

L2EN0  = JC  * HALFCG  - ONfed: 

3 

00006120 

L2s 

00  KC  * JC  TO  L2END; 

4 

00006130 

STYPE  = TYPEC LINDEXC KC) ) ; 

4 

00006140 

/* 

/* 

CONTERS  FOR  CALL.  10.  ASSIGN  ST.  */ 

*/ 

00006150 

DO  LT  * 1 TO  3; 

5 

00006160 

IF  LTYPECLT ) = STYPE  THEN  * 

5 

00006170 

DO; 

7 

00006170 

LCTCLD  = LCTCLT)  ♦ CNEB: 

7 

00006190 

IF  LCT I LT)  = TESTCG  TFEN 

7 

00006200 

do; 

9 

00006200 

FTTPE  =>  LTVPEI  LTI  ; 

9 

00006220 

nenD  = kc; 

9 

00006230 

30  TO  L3 : 

9 

00006240 

/* 

END: 

9 

00006250 

END  L2: 

4 

00006260 

/* 

/* 

NO  CG  IF  NEND  IS  STILL'  0 */ 

*/ 

00006270 
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IF  (NEMO  = ZB i THEN 
GO  TO  14; 


hO 

ui 


/*  /*  FOUND  CG.  DOES  IT  EXTEND  FURTHER  ? 

L3: IF  (NFN0=TEND)  THEN 

oO  TO  FIRST; 

/*  


*/ 


DO  KC  =■  NEND  ♦ ONEd  TO  TEND; 

IF  TYPE  (LINOEX(KC))  = F TYPE  THEN 
NEND  * KC! 

ELSE  _ _____  

GO  fO  FIRST; 


/* 


End; 

/*  /*  FIND  FIRST  CG-TYPE  STATEMENT  */ 

FIRST;  DO  KC  = JC  TO  JC  ♦ HALFCi,  - TESTCG: 

IF  TYPE ( L INDEX (KC ) ) » FTYPE  THEN 

00; 

NST  * KC; 

return;  _ 

ENO; 

la:  END  Li; 

/*  /♦  NO  CG.  NST  AND  NEND  STILL_0 */ 

RETURN; 

/*  /*  ENTER  HERE  TO  SEARCH  FOR  CG  IN  PARTIALLY  FILLED  BUFFER  AT  END 

CGENOi ENTRY! NST, NENDI : 

JEND  = COUNT  «■  ONEB  - HALFCG: 

TEND  = COUNT; 

GO  TO  LC; 


*/ 


/*  .... 

END  CGFIND: 

/*  -1  IS  HIT.  IF  TESTCG  STATEMENTS  OF  A GROJP  ARE  OF  ONE  TYPE  (ASSIGNMENT,  10.  OR  CALL ) « RETURN  NST 


* OF 


/*  /*  *********  PAGE  36  IN  HANDWRITTEN  COPY  *********  */ 

/*  /*  PROCESSES  CALL.  GO  TO.  EXIT,  STOP.  WAIT.  DELAY,  RETURN  STATEMENTS 
CTRLC:  PROC; 

/*  /*  ENTRY  FOR  CALL  ~ 

T YP E(R INDEX)  * LTYPEI3I: 

IF  (COUNT  = ONEB)  THEN 
GC  TO  ONCl: 


*/ 


/*  /»  FIND  PRECEDING  LINE  JSKIPCOCE,  NO  SKIP_ BETWEEN  SUCCESSIVE  CALLS  */ 

PT  * SUBPTRI RINOEXI  ; 

IF  (SKIP(PTI  * 5)  £ (TYPE(LINDcX(COUNT  - ONEB))  = LTYPEI3)  ) THEN 
SKIP(PT)  = ZB; 

SKIPIR INDEX)  = 5:“ 

IF  (PLEV-.*0)  THEN 
DO: 

■ LEVEL (RINDEX) 

plev  = 0; 
end: 


ONCl: 
0NC2 : 


PLEv  ; 


ELSE 

LEVEL(RINDEX)*CLEVEL: 
CALL  STEXT(LINE); 


/* 


return: 

/*  /*  ENTRY  FOR  GO  TO  ST. 


*/ 


CTRLG: 


ENTRY*. 

TYPE(RINOEX) 
GO  TO  ONCl: 


LTYPE(A) : 


3 

00006280 

4 

00006280 

*/ 

*/ 

00006300 

3 

00006310 

4 

00006310 

*/ 

4 

00006330 

4 

00006340 

5 

00006340 

4 

00006360 

5 

00006360 

*/ 

4 

00006380 

+/ 

00006390 

4 

00006400 

4 

00006410 

6 

00006410 

6 

00006430 

6 

00006440 

6 

00006450 

3 

00006460 

*/ 

00006470 

2 

00006480 

+/ 

00006490 

2 

00006510 

2 

00006520 

2 

00006530 

2 

00006540 

*/ 

2 

00006550 

*/ 

00005990 

*/ 

00006570 

*/ 

00006600 

2 

00006620 

*/ 

00006630 

2 

00006640 

2 

00006650 

3 

00006650 

*/ 

♦/ 

00006660 

2 

00006680 

2 

00006690 

3 

00006690 

2 

00006720 

2 

00006730 

4 

00006730 

4 

00006750 

4 

00006760 

4 

00006770 

2 

00006780 

3 

00006780 

2 

00006800 

*/ 

2 

00006810 

*/ 

00006820 

3 

00006830 

3 

00006840 

3 

00006850 

Moorr  Buvnns  romn.  Inc 


r. 
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/*  

/*  /*  ENTRY  FOR  ALL  OTHER  CONTROL  ST.  */ 
CTRLO:  ENTRY: 

TYPE(RINDEXl  * LTYPc(<.i: 
SK  IP( R INDEX  I = 3: 

GO  TO  0NC2; 

/«  


END  CTRLC; 

DECLARE:  PROC: 

/*  /*  FOR  DECLARATIONS.  ALLOCATE  AND  DEFAULT  ST.  */ 

DCL  (NCHAR.LI  BIN  FI XED( 15.01  . 

SLEV  DEC  FIXEDI2IS 
/*  /*  FIRST  LINE  OF  STATEMENT  */ 

LEVELIRINDEXI  = CLEVEL: 

“TYPE(R IKOEXI  = LTYPE(5»: 

SK  I P <R INDEX  I = 0N5B; 

n char^  - js  ; 

/*  /*  SUB  ST  'DCL*  FOR  FULL  WORD  *'/ 

IF  ( SUBSTRlLlNc.1,7)  * 'DECLARc'I  THEN 

LINE  * 'DCL'  II  SU3STR(LiME,ttl : 

7*  /*  SEPARATE  PHASES  : FIND  FIRST  COMMA  NJT  IN  UJOTE  DR  PARENS 
F COMMA:  CALL  FINOCOMILI: 

/* 

" TEMLINE  « SUBSTRI LI NE.l »L)  : 

/*  /*  FIRST  LINE  STARTS  AT  CURRENT  MATGIN  */ 

IF  (NCHAR  = 51  THEN 
GO  TO  PUT! : 


FO  /*  /*  FOR  OTHER  LINES  */ 

/*  /*  FIND  MARGIN.  PREPARE' TO  SfCRE  */ 

IF  SUBSTR(TEMLINE»l.2l=BRK(6l  THEN 

do: 

Tline=lTne: 


L*INDEX( TEMLINE. BRK( TIH-l:,. 
LINE=SUBSTR(TEMLINE.l .Li : 
call  Comment: 


LI NE  = TLI NE  : 
GO  TO  PUT1A: 


*/ 


IF  '{ VERIFY!  SUBSTRITEMLINE. I .li  . •0123456789*  ) = ZBI  THEN 

SLE  V=DEC ( SUBS TP (TEMLINE. i . I Nu EX (TEMLINE. * • l-Ii.2,0): 
ELSE  _ 

SLEV  = i: 

LEVEL(RINOEXi  * CLEVEL  ♦ SLEv: 

SKIP(RINDEXI  * ZB: 

PRE  F IX ( R INOE  X. * ) * * • : 

TYPE(RINOSX)-"  : 

LABEL! RINDEX.*!*' * ; 

/*  /*  STORE  PHASE  IN  BUFFER  */ 

PUTl:  CALL  STEXT  (TEMLINE!  : 

/*  

7*  7*  MOVE  LINE  UP  OPERATE  ON  NExTTART  *1 
PUTl A:  LINE  = SUBSTR(LINE.L  * II; 

/»  /*  DELETE  LEADING  CLANKS  */ 

IF  VERIFYILINE. BLANK )-*0  THEN 

LINE  * SU3STR(LINE< VERIFy(LlNE.BLAXK) I ; 

/»  /»  FINISHED  ? */ 


*/ 

*/ 

00006B60 

4 

00006870 

4 

00006880 

4 

00006890 

4 

00006900 

*/ 

2 

00006910 

2 

00006920 

*/ 

00006930 

2 

00006940 

3 

00006940 

*/ 

00006960 

2 

00006970 

2 

00006980 

2 

00006990 

2 

00007000 

*/ 

00007010 

2 

00007020 

3 

00007020 

*/ 

00007040 

2 

00007060 

*/ 

2 

00007070 

*/ 

00007080 

2 

00007090 

3 

000 07090 

*/ 

*/ 

00007110 

*/ 

00007120 

2 

00007121 

4 

00007121 

4 

00007122 

4 

00007123 

4 

00007124 

4 

00007125 

*/ 

4 

00007126 

4 

00007127 

*/ 

4 

00007128 

2 

00007130 

3 

00007130 

2 

00007160 

3 

00007160 

2 

0000713d 

2 

00007190 

2 

0000720 0 

2 

00007201 

2 

00007202 

*/ 

00007220 

2 

00007230 

*/ 

*/ 

00007240 

2 

00007241 

*/ 

00007260 

2 

00007270 

3 

00007270 

*/ 

00007290 

9 


% 
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IF  LINE  * ••  THEN 

GO  T-j  oclend; 

/*  . 

/*  /*  NO,  REPEAT  */ 

NCHAR  = CNEB; 

RINOEX  - ADOPTRCRINOEX) ; 

GO  TO  FCCMMA; 

OCLEND: IF  SK I P( R INDEX)  * ONEB  THEN 

SKIPCP.INDEXI  = TW3B; 

ELSE 

SKIPCRINDEX)  * 3; 

END  DECLARE: 

/*  /♦  ELSE  IS  CALLED  BY  PUSHPUL  */ 

ELSE:  PROC: 

TYPECRINDEX)  = LTYPEC4): 

SK I P( R INDEX ) = ZB: 

/♦_/*  POP  UP  USED  UP  IFS  */ 

DO  WHILE(STACK1=*ELSE* ) : 

CALL  POPUPC • ELSE  1 ) : 

/_*  

C LE  VEL=  STAC  K 3—1 : 

CALL  popif: 

/♦  

END  : 

/*  /♦  CHECK  FOR  HATCHING  IF  */ 

/*  /*  GB  ♦/ 

IF  STACK  1-**  • IF  • THEN 
DO; 

PUT  SKIP  LISTC ***SRaJR  in  IF. ••ELSE  STRUCTURE*** ) 
STOP: 

eno; 

/*  /*  END  OF  GB  */ 

/*  /*  ENTER  IN  PUSHDOWN  LIST  WITH  NULL  LABEL  */ 

FLAG**0*8: 

CALL  PLSFOCNC *ELSE* tMTLABI : 

/* 

CLE VEL=STACK3; 

LEvEL(RINOEX»=CLEVEL-l ; 

/*  /*  f5  ELSE  FOLLOWED  BY  SEMICOLON  (EMPTYJ  */ 

TEMLINE  * SUBSTRC  LI NE,5) ; 

TEMLINE  = SU BSTRCTEMLINE, YE RIFYCTcMLlNE, BLANK)); 

IF  (SUBSTRC  TEMLINE titl)  * BRK (3)1  THEN 

do; 

CALL  STEXTCLINE): 

/* 

THFL  = TWCB; 
return: 

END: 

/*  /*  ELSE  IS  FOLLOWED  BY  TEXT,  SEPARATE  ELSE  */ 

CALL  ST EXT ( * ELSE* I : 

/*  /*  REMAINING  TEXT,  NEW  LINE  ♦/ 

IF  SUBSTRC  TEMLINE ,1  ,21 =BRKC  6)  THEN 
DO: 

RI NDEX=ACDPTRCRlNOcXI ; 

TLINE*LINE: 

— L = INDEX  ( YEWUI  tfE,  B RkcTITVI; 

LI  NE 3 SUBSTRC  TEMLI NE.i ,LI  ; 

CALL  COMMENT: 


2 00007300 

3 00007300 
..  */ 

*/  0000732 0 

2 00007330 
2 00007340 
2 00007350 

2 00007360 

3 00007360 

2 00007380 

3 00007380 
2 00007*00 

*/  00007410 

2 00007420 
2 00007440 

2 00007450 

*/  00007451 

3 00007452 
3 00007453 

• • */ 

3 00007454 
3 00007455 
• • */ 

3 00007456 

*/  00007460 

*/  00007470 

2 00007471 

4 00007471 
4 00007472 
4 00007473  ~ 
4 00007474 

*/  00007475 

*/  00007490 

2 00007500 
2 00007501 
• • */ 

2 00007502 
2 00007503 
*/  OOO07520 

2 00007530 
2 00007540 
2 00007550 
4 00007550 
4 00007570 
..  */ 

4 00007580 
4 00007600 
4 00007610 
*/  00007620 

2 00007640 
..  */ 

*/  00007650 

2 00007651 
4 00007651 
4 00007652 
4 00007653 
4 00007654 
4 00007655 
4 00007656 


/*  */ 

LINE-TLINE;  4 00007657 

TEMLINE*SUBSTR(TEMLi  ; * 00007658 

TEMLlNE*SLBSTR(TEMLlNc.rffcRIFY(T=MLINE, BLANK)  > : 4 00007659 

ENO:  _ 4 00007660 

RINDEX  * 'ADDPTR(RINDEX)  ; 2 00007661 

COUNT*CCUNT*ONEBJ  2 00007662 

L INDEX ( COUNT )*RINDE X < 2 00007663 

LINE  = 7EMLINE;  2 00007670 

/*  /*  ANY  PREFIX  ? */  */  00007680 

CALL  RLABEL;  2 00007690 

/*  ................  ..............  */ 

/*  /*  IS  THIS  ON  IF  CR  00  STATEMENT  */  */  00007700 

CMND  * SliB STRlLlNE.lt 31  • 2 00007710 

IF  CMND*  *BEG IN  • 1 CMND='8EGIN : • J CMN0»'D3  • I CMNO*'DO:'  THEN  2 00007720 

CLE VEL*CLEVEL-1  ; 3 00007720 

END  ELSE:  2 00007810 

FINDCOM:  PROC ILL  I • ' ' " 2 0 0007820  ' 

/*  /*  EXAMINES  LINE. RETURNS  LL  = POSTION  OF  FIRST  COMMA  NOT  IN  QUOTES  OR  PARENS.  IF  NONE.  LL  = LENGTH  ILINEI.  */  00007830 

/*  */  */  00007830 

OCL  (KC.FAREN.LLI  BIN  FIXED(ia.J) . " 2 00007860 

QUOTE  BIT(1>  INITI’O’BI.  3 00007860 

KCt-AR  CHAR:  3 00007860 

PAREN  * ZB: ' 2 00007890 

Ll:  00  KC  = 1 TO  LENGTHILI NEl  - l;  3 00007900 

KCHAR  * SUBSTRILINE.KC.il:  3 00007910 

lo  /*  /*  "BonT  LOOK  INS  IDE  QUOTES  OR  PARENS  */  */  00007920 

g IF  IKCHAR  = BRKI2II  C (PaRcN  * 2BI  t (-.QUOTE)  THEN  3 00007930 

GO  TO  FCOH : 4 00007930 

/*  /*  IS  IT  OUOTE  OR  PAREN  ? */  */  00007960 

IF  (KCHAR  * BRKI1H  THEN  3 00007970 

-0(5:'  ~~  - --  5 00007970 

OUOTE  = -.QUOTE:  5 00007990 

GO  TO  L3:  5 00008000 

/*  . ..T..T. . . .... ......  r.  ...«rr;..  */ 

ENO:  3 00008010 

IF  (KCHAR  * BRKI4I I THEN  3 00008020 

PARIN'*  PaREN *■  ONEB;  4 00008020 

tLSE  3 00008040 

' IF  (KCHAR  * BRK(5M  TrlEN  4 00008040 

00:  6 00009040 

PAREN  = PaREN  - ONEB;  6 00008070 

IF  PAREN  < IB  THEN  6 00008080 

GO  TJ  PERROk;  7 00008080 

/*  4/ 

ENO:  6 00008100 

L3j  . END  Lll  ' " ‘ 3 00008110 

IF  (CUCTEI  I (PAREN  -«  01  THEN  2 00008120 

GC  TO  PERROR:  3 00008120 

/* *f 

L4:  LL  = LENGTH!  LINE1 : 2 00008140 

RETURN:  2 00008150 

/*  /*  FOUND  COMMA  */  " ’ */  00008160 

FCOM:  LL  * KC:  2 00008170 

RETURN:  2 00008180 

PERROR:  PUT  SKIP  LIST  ( '**UNBALANCEO  PAREnS  OR  QUOTES**');  2 00008190 

GO  TO  L4:  2 00008200 

/»  *' 


Mocr*  ftwnet*  Inc 


# k i ^ 


PAG?  IT 

n END  FINCCOM:  2 00008210 

if:  __  PROC:  2 00008220 

OCL  L BIN  FIXED415.0):  2 00008230 

/*  /*  FOR  Each  IF  CLALSE  */  */  00008240 

_ flag  = • 1*B5  2 00008250 

OVER:  TYPECR  INDEX)  * LTYPE44 ) ; 2 00008260 

SK I P ( R INDEX)  * ZB;  2 00008270 


CALL  PL  SHDON  4 • I F • . MTLABI  ; 2 00008290 

/♦  */ 


LEVEL<RlNOEX)*CLEVEL-l ; 


/*  /*  SEPARATE  FIRST  PHASE  THRU  THEN  */ 

L = INDEX4  LI NE . 1 THEN  •) ; 

IF  L * ZB  THEN 
00; 

L - I NDEX ( LINE t 9 then;*); 
IF  L s ZB  THEN 


GO  TO  THENERR; 


/*  

/*  /*  FOUND  • T HE N ; • t EMPTY  CLAUSE 

ELSE 


*/ 


oo; 

TLlNE*$UBSrR4LlNEt  1 .L*5)  ; 
CALL  STEXTC  TU  NE  ) ;' 


/* 


HO 

ui 

v/i 


GO  TO  TESTFN; 


TS- 


ENG; 


ENO; 


/♦  /*  FOUND  •THEN  • ♦ / 

TLINE*SU8STR CLINE »1 . L*4) ; 
CALL  STFXTCTLINE) ; 


/*  /*  UPDATE  P TR ♦ LINE.  DELETE  LEADING  BLANKS  */ 
LINE  * SLBSTR4 LINE .L  ♦ 6); 

L INF  * SUBSTrTL  INE.  V E P I F Y ( L I Nc  . BL ANKTI  5" 
IF  SUB ST R(LINE.1*2)SBRK(6)  THEN 

do; 

kl NDEX-ADDPTR ( RINDEa) S " 

TL INE-LI NE  ; 

L- I NDE X( TLINE.BRKC7I  l*i; 

LI NE*SUBSTRC  TLINE .1 #L|  S 
CALL  COMMENT; 


/* 


LI  NE*SUBSTR( TLINE  .LUI ; 

LINE- SUBS  TRCLINE.VEKIFYClINE.6L AN Kl ) ; 
END; 

addptrc  r Index) ; 


TinoEx 
count*ccunt+oneb; 

LINDEXCCOUNT ) *RI  NDE  X ; 

“/♦  'CHECK  FOR  TRFFTX  FOR  NEW  LINE~“*/ 

CALL  RLABEL; 

IF  SUBSTR(LINF*1.3)-#D0  ■ I S JBSTk C LINE . 1 . 3 ) = • DO; • I 


SUBSTRCL IN6. 1.6)* •BEGIN 


SUBffR  4 LlNE.T. 6 > * • BEGIN;  • "THEN 
CLE VEL=CLE VEL-1 ; 

/♦  /*  ANOTHER  IF  ? ♦/ 

rF~(  SU  B S T R f L 1 N £ .TY31 
GO  TO  OVER; 


1TF  H T 4SCJBSTRCLINE.1 .3  ) = 'IF(»>  THEN 


2 00008300 
*/  00008310 

2 00008320 
2 00008330 
4 00008330 
4 00008350 

4 00008360 

5 00008360 
..  ♦/ 

♦/  00008380 

4 00008390 

6 00008390 
6 00008410 
6 00008411 

..  */ 

6 00008412 
..  */ 

6 00008430 
4 00008431 

*7  00008^0 

2 00008450 
2 00008451 
..  ♦/ 

*/  00008460 

2 00008470 
2 00008480 
2 00008481 
4 00008481 
4 00008482 
4 00008483 
4 00008484 
4 00008485 
4 00008486 
..  ♦/ 

4 00008487 
4 00008488 
4 00008489 
2 00008490 
2 00008491 
2 00008492 
*/  00008500 

2 00008510 
2 00008511 

2 00008511 

3 00008511 

*/  00008520 

2 00008530 

3 00008530 
..  */ 
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n 


RET:  THFL  - 1: 

return: 

7*~7*  NO  Hti&i  PRINT  MESSAGE*  FUDGE » GO  un  */ 

THENERR:  PUT  SKIP  LIST! • **MI SSI NG  1 • THeN • • IN  IF  STATEMENT **• I 5 

PUT  SKIP: 

CALL  ST EXT  CLINE): 


/* 


/* 


/* 


/*  RETURN^ TO  MAIN  PROGRAM 
GO  TO  P3 : 


*/ 


END  IF: 

IOSUB:  PROC: 

/*  /*  PROCESSES  10  STATEMENTS.  SKIP  LINE  BEFORE 
TYPE (R INDEX ) = LTYPEI2) : 

Tf  (plEv  -*  0)  Then 


ANO  AFTER  EACH  10  OR  GROUP  OF  10  S 


*/ 


ro 

un 

cn 


00: 

LEVEL! RINDEX)  * PLEv: 

PLEV  * o: 

END: 

ELSE 

LEVELCRINOEXI  * CLEVEL: 

/*  /*  IS  PRECEDING  STATEMENT  ALSC  10  ? */ 

IF  COUNT  * 1 THEN 

go  to  rnt 

IF  <TYPE<LINDEX<COUNT  - 1)1  * LTYPE<2 ) ) THEN 

do: 

PT  * SUSP TR< RINDEX) : 

IF  SKIPIPT)  = TWOB  THEN 

skipipt)  = oneb: 

ELSE 

SKIP<PT)  * I b; 

SKIPIRINDEX)  a 3: 

END: 


ELSE 

Ills  SK I p<  Rl NDEX ) = TwOB: 

7*  /♦  ENTER  IT  BUFFER  */ 

CALL  STEXTILINE) : 


/♦  . 

END  TOStTB; 

MOVUP:  PROCITFRCO) ; 

/*  /♦  CALLED  AFTER  OUTPUT  TO  MOVE  UP  REMAIN*  bUFFeR  LINES.  ACTUALLY  ONLY  THE  LINDEX  TABLE  IS  CHANGED 

^♦  < POINTERS  To  FIrSTlTNE  of  each  STATEMENT  in  buffert.  COUNT  IS  the  number  of  statements  in  buffer,  throo 
/*  IS  THE  NUMBER  OF  LAST  ST  TO  BE  MOVED  OUT.  UPDATES  COUNT. RfNOEX  */ 

DCL  < THROO. JCT)  BIN  FIxED!15,U): 
count  = count  - throo: 

IF  COUNT  * ZB  THEN 

return: 

DO  JCT  * 1 TO  COUNT!  ' ' 

L INDEX! JCT)  * LINDEXI JCT  ♦ THROO); 

END : 

"7*“ 7*  ZERO  UNUSED- INCiCES  *7”  “ 

DO  JCT  * COUNT  + l TO  2 Ji 
L INDEX! JCT ) = ZB; 

- 

END  MOVLP: 

ONSUB:  PROC: 

/*  /*  P'KqCES'SES  ON  TCN OTTl ON . sI~G N AL  AND  RcVtRT  STATEMENTS.  PR6DEDES  STATEMENTS.  PRECEOES  EACH  BY  BLANK  SPACE 
/*  AND  COTTED  LINE.  FOLLOWS  BY  DOTTED  LINE.  UNLESS  CN  ST.  INCLUDES  A BEGIN  GROJP.  WHEN  ONFLAG  IS  SET  TO  1 
/»  AND  THE  FOLLOWING  DOTTED  LINE_IS_ IMPLEMENTED  AFTER  THE  CORRESPONDING  END.  */ 


2 00008560 
? 000085T0 
*/  00008580 

2 00008590 
2 00008600 
2 00008610 
..  */ 

*/  00008620 
2 00008630 
..  */ 

2 00008640 
2 00008650 
*/  00008660 
2 00008680 
2 00008690 
4 00008690 
4 00008710 
4 00008720 
4 00008730 

2 00008740 

3 00006740 

*/  00008760 

2 00008770 

3 00008770 
2 00008780 

4 00008780 

4 00008800  ~ 

4 00008810 

5 00008810 
4"  0000*830 
5 00008830 
4 00008850 
4 00008860 

2 00008870 

3 00008870 

*/  00008890 

2 00008900 
..  */ 

2 00008910  ~ 
2 00008920 
*/  00008930 

♦/  00008930 

*/  00008930 

2 00008990 
2 00009000 

2 00009010 

3 00009010 
3 00009030 
3 00009040 
3 00009050 

*/  00009060 

3 00009070 
3 00009080 
3 00009090 
2 00009100 
2 00009110 
*/  00009120 

*/  00009120 

*/  00009120 


Moor*  6uvrw»*i  Fo*n>».  I«c 


J 


P DCL  LL  FIXED  BINC15.3); 

TYPE!R INDEX)  * L TYPE ( 6)  : 

- IF  IPLEV  01  THEN 

do; 

__  _ LE VEL( RINDEX)  = PLEv: 

PLEV  * 0; 

END; 

ELSE 

LEVEUP  INDEX)  = CL5VEL; 
SKIPCRINDEX)  = 7; 

/♦  /♦  IS  LAST  (NON-BLANK)  WORK  •BEGIN1  ? */ 

IF  LENGTH! LINE)  < 7 THEN 
GO  TO  TSTOR; 
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*/ 


/♦ 


Ll: 


DO  LL  - LENGTH(LINE)  - l TU  6 BY  -1: 

IF  SUBSTRCLINE.LL.l)  = BLANK  THEN 
GO  TO  L2: 

IF  SUBSTR(LINE.LL-5«6) ’*  •BEGIN*  THEN 
DO: 

ONFLAG  * *1*B5 

SKIPCRINDEX)  » 

END; 

GC  TO  TSTOR; 


00009200 

00009210 

00309220 

00009220 

00009220 

00009240 

00009250 

00009260 

00009260 

00009280 

00009290 

00009300 

00009300 

00009320 

00009330 

00009330 

00009350 

00009350 

00009370 

00009380 

00009390 

00009400 


/*...« 

L2s 

TSTOR: 


END  Ll; 
CALL  STEXT(LINE); 


ro 

KJl 


/*  

END  ONSLB: 

OUTPUT:  PROC(TFRU): 

/*  /*  PRlNf5~$TATEMENTT"l  - THRU  */ 

✓*  /*  WRITTEN  FOR  8C  OR  120  COLUMN  PRINTOUT  ON  SYSTEM  FILE 
DCL  !R  I • THRU*  NV«  LASTN.  I)  alN  FIXED(15«0)» 

(LEV*  MCT~DEC  FIXED  (3.0) * 

(CMT3  I NIT  (•/*  •)♦  CMT6  INIT  (•  */  • ) ) CHAR(3)5 
IF  THRU  - ZB  THEN 


*/ 


+/ 


return; 

/*  /*  ALL  LINES  ARE  AT  SAME  LEVEL  (RULE  1) 
LEV  * LEVEL! LINDEX< l) ) : 

MC  * M AR G IN ( LE V)  ♦ l ; 

/*  /*  FIND  POINTER  TC  LAST  OUTPUT  LINE  */ 
IF  THRU  * COUNT  THEN 


LASTN  * RINDEX: 

ELSE 

LASTN  * SUBPTRf  L INDEX! THRU  «■  i)); 
Rl  * StBPTR! L INDEX! 1 ) ) ; 

/*  /♦  PRINT  ONE  LINE  AT  A TIME  */ 

LPO:  DO  I * 1 TO  50: 

RI  * ADDPTRCRI ) : 

LEV*LEVEL( RI ) ; 

MC-*  MARGIN!  LEV) *1 ; 

/♦  /♦  IS  IT  COMMENT  7"  */ 

IF  TYPE(RI)  = L T YPE  (71  TriEN 
DO; 

PUT  FIL£( SYS PRINT)  EDIT 


*/ 


*/ 


*/ 


*/ 


OCMTJ 


(CMT8  *TEXT! RI ) • CMTE , SE3#  ( R I ) ) 
(COL (21 •AtAfC0L(NCJL-2). AtX(4) .A) ; 

GO  TO  lpa; 


/*  • 

/♦  /*  GB  ♦/ 


2 

3 

3 

2 

"3 

2 

2 

2 

3 

2 

3 

2 

3 

3 

3 

3 

3 

5 

5 

5 

5 

*/ 


*/ 


END; 


00009460 

00009480 

00009480 

00009480 

00009510 

00009510 

00009530 

00009540 

00009550 

00009560 

00009570 

00009570 

00009590 

00009590 

00009610 

00009620 

00009630 

00009640 

00009641 

00009642 

00009650 

00009660 

00009660 

00009680 

00009680 

00009710 

00009711 

00009711 


P AGE 


/*  /*  NOT  CIMKENT:  IS  TEXT  NULL  ? */ 

IF  TEXT  I R 1 1 * V THEN 
DO  ; 

NTXT:  PUT  FILEISYSPrU  XT)  EDI T ( PREF IX( RI • « ) • LABEL (R I • * I *LEV» SEU«(» 1 I ) <C0L<2).10 

A*CCL( NCOL +2 ).F(2) • X ( l ) . \) ; 

GO  TC  lpa: 

/*  .... 


fS3 

KJl 

OO 


END ; 

/* "/♦  LINE  HAS  TEXT  •/ 

TXT:  PUT  FiLEI SYSPR INTI  EDIT  I PREFIX! RI  ♦*)  . LABE  L ( Kl * * I 

COL (MCI*  A*  CCL ( NCQL+2 I » F4  2 ) .X  ( 1 1 . A)  ; 

LPA:  ' IF  RI  = LASTN  THEN 

GO  TO  LPOLT : 


/*  

T7*E1  End  Lpo: 

/*  /*  ALL  LINES  PRINTED*  LOOK  FOR  AFTER  SHIP  Ok  DOT  */ 

/*  7_XbX  RULES  2 & It  ONLY  ^AST  LINE  CAN  H*We  FOLLOWING  SKIP  OR  DOT 
LPOUT:  I F SKI PC  LASTN)  * 0 THEN 

return: 


TEXT ( R I I * LEV  * SEO* (R I ) ) 


*/ 


I COL ( 2 I 


ELSE 

NV  > SKIP! LASTN! * 

/*  /♦  PRINT  DOT.  SKIP  */ 

PUNC:  IF  (NV  = 51  I (NV  * A)  THEN 

if  (NCOL  * T2f  Then 

PUT  FILE(  SYSPRINT)  EDIT  (CMTB.  (65)  CMTE)  (C0L(2).  A*  A*  COH70I.  All 

„ELSE„ 

"PUT  FILE(  SYSPRINT)  cJIT  ( CMTB  * (112)  •.«*  CMTE)  (COL(2).  A»  A.  C0L(117).  A); 
IF  (NV  = 5)  I (NV  * 2)  THEN 
PLT  SKIP; 

return: 

/*  /*  IF  VERY  FIRST  STATEMENT  HAS  PRE-SKIP  ETC..  ENTER  FERE  */ 

OUTFST : ENTRY( NV2 ) ; 

IF  (NV2  * II  THEN 
NV  = 3; 


( 1 0)  A 


20 

*/ 


*/ 


*/ 

*/ 


*/ 


*/ 


ELSE 

~mNV 2 * 61  THEN 
NV  * 5; 

ELSE 

if  ( nv2  * 8i  Then 


NV  * 4; 


GO  TO  PLNC; 

/*  


END  OUTPUT: 

PEND:  proc: 

/*  /*  PROCESSES  END  ST.  WHICH  MAY  TERMINATE  PROC.  DO.  OR  BEGIN  BLOCK 
OCL  LAB  CHAR  431)  VAR; 

DCL  LVAR  LABEL  (FAN3.  PLAlNiJ." 

DCL  (LIND.  IFAN)  BIN  FIXED!  15*0) S 
TYPE(RINOEX)  * LTYPE4 A) « 

LEVELIRINDEX)  * CLEVEL: 

/*  V*  SKIP  IF  THIS  Ts  END  OF  a CCNDlTTON  BLOCK  */ 

/*  /*  BEGINNING  GB  */ 

IF  CNFLAG  THEN 

: SkT  PTR I NSE  x )**a  ; 


ELSE 

SKIP4RIN0EXI»2BS 
/*  7*  STORE  TEXT  */ 

CALL  STEXT(LINE) 5 
IF  (QNFLAG)  THEN 


UPDATES 


PUSHOOWN  LIST  AND  LEVEL 


*/ 


*/ 


*/ 

*/ 


*/ 


00009720 
3 00009730 
5 00000730 
5 00009750 
5 00009750 
5 00009780 
*/ 

5 00009790 
00009800 
3 00009810 
3 00009810 
3 00009860 
A 00009860 
*/ 

3 00009880 
00009890 
00009900 

2 00009920 

3 00009920 

2 00009940 

3 00009940 
00009960 

2 00009970 

3 7)0009970 

A 00009970 

3 00010020 
A 00010020 
2 00010060 
3 00010060 
2 00010080 
00010090 
2 00010110 

2 oooiorar 

3 00010120 

2 00010140 

3 00010140 

4 0001 0140 
3 00010170 
A 00010170 

5 00010170 
2 00010200 

*/ 

2 00010210 
2 00010220 
000TD230 
2 00010260 
2 00010270 
2 00010280 
2 00010290 
2 00010300 
00010310 
00010320 

2 00010321 

3 00010321 

2 00010322 

3 00010322 
00010323 

2 00010324 
2 00010325 


Moore  Boiifvm  Form*,  ln< 
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ro 

un 

iO 


DO: 

onflag*'0'b: 

return: 

end; 

/♦  /♦  END  0^  G8  V 

/*  /*  is  END  FOL LOWE 0 BY  IDENTIFIER  ? */ 

TEMLIN6  * SUBSTR( LI NE«4) : 

TEMLINE  * SUBSTR! TEMLINE .VERIFY! T EML INE  .BLANK ) ) ; 
IF  LENGTH!  Tt  ML  INE  > * 1 THEN 
GO  TO  PLAIN; 

/»  

/*  /*  SET  IDENTIFIER  INTO  LAB  ♦/ 

/*  /*  GB  */ 


FANCY: 


/*  /*  GB  */ 


L AB=SUBSTR! TEMLINE. It LENGTH ! TEMLINE) -II  I I • : • ; 
LIND  = INDEX ( LAB . BLANK)  : 

IF  LIND  -«=  ZB  THEN 

LAB*SUB  STR( LAB* l.LIND-ll  4 i • : • ; 

/*  /♦  TEST  FOR  ERROR  IN  PUSHDOWN  LIST  */ 

FAN 2: L VAR  - FAN3: 

GO  TO  sterr: 

/*  ••••I 

/*  /*  RETURN  HERE  IF  NO  ERROR  */ 

/*  ✓*  DOES  IDENTIFIER  MATCH  STACK  LABEL  ? */ 

FAN3:  DO  IFAN  * 1 TO  5; 

' _IF_«STACK2!  IFAN)  « LAB)  THEN 

IF  ! STACK 1*' ENTRY • J THEN 
GO  TC  ENTFRR: 

ELSE 

GO  TO  HAVIT: 

/*  

/*  /*  IDENTIFIER  NOT  IN  THIS  STACK  LEVEL 
ENO: 

IF  STACK  1 = •ENTRY'  THEN 
FLAG  = •0,B: 


♦/ 


ELSE 


FLAG 


•1*B5 


CALL  PCPUP ! S TACKl ) ; 


/*  t:.... 

/♦  /*  KEEP  LOOKING  FOR  LAB 
GO  TO  F AN2  ; 


*/ 


/*  

/*  /*  JUST  END  NO  IDENTIFIER  */ 

/*  /*  TEST  FOR  STACK  ERROR  */ 

PLAIN:  LVAR  * PLAIN!; 

GO  TO  STERR; 

/*  

/*  /*  RETURN  HERTTF  CK  */ 

PLAIN!:  IF  STACK1  * 'ENTRY*  THEN 

do; 


/* 


FLAG  = 'O'B: 

CALL  POPUP ! STACKl ) ; 

"GO"  TO  TCaTN  5 ' 


/♦  /^>opup  i lEvR  */ 


end: 


HAVIT: 


FLAG  = • l'B: 

CALL  P0PUP!STACK1) ; 


A 

00010325 

A 

00010326 

4 

00010327 

4 

00010328 

*/ 

00010329 

*/ 

00010410 

2 

00010420 

2 

00010430 

2 

00010440 

3 

00010440 

*/ 

*/ 

00010460 

*/ 

00010470 

2 

00010471 

2 

00010480 

2 

00010490 

*/ 

00010490 

3 

00010490 

*/ 

00010510 

2 

00010520 

2 

00010530 

*/ 

*/ 

00010540 

*/ 

00010550 

3 

00010560 

3 

00010570 

4 

00010570 

5 

00010570 

4 

00010600 

5 

00010600 

*/ 

*/ 

00010620 

3 

00010630 

2 

00010640 

3 

00010640 

2 

00010660 

3 

00010660 

2 

00010680 

*/ 

*/ 

00010690 

2 

00010700 

*/ 

*/ 

00010710 

*/ 

00010720 

2 

00010730 

2 

00010740 

*/ 

*/ 

00010750 

2 

00010760 

4 

00010760 

4 

00010780 

4 

00010790 

*/ 

4 

00010800 

*/ 

4 

00010810 

♦/ 

00010820 

2 

00010830 

2 

00010840 

Maor*  8u»ipeti  form\,  Inc 


— 


[ ’ IF  $TACK1=' IF*  THEM 

CLEVEL=STACK3: 

• CLEVEL-STACK3: 

LEVEL! R INDEX )*CLEVEL«T: 

RETURN J 

/*  /*  ERROR  RETURSN*/ 

ENTERR:  PUT  SKIP  LIST! '**LABEL  ON  END  STATEMENT  SHOULD  NOT  MATCH  'll 

/*  /*  TRY  TO  RECOVER*/ 

GO  TO  PLAIN!; 

/* . 
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• ENTRY  NAME**  ' I ; 


/*  /*  TEST  FOR  STACK  ERROR  */ 

STERR!  IF  STACK  1** TOP*  I CLEVEL«0  THEN 

00: 

PUT  SKIP  LIST! •♦♦UNMATCHED  END  OR  ERROR  IN  IF. ..ELSE  *11 
STOP: 
end: 

GO  to  lv*r; 


•STRUCTURE*** ); 


/* 


N3 

<n 

o 


END  PEND; 

POP IF:  PROC: 

V*  7*  POP  IP  ICACLEO  BY  PUSHPUL)  CR  ENTRY  PUPcL  (CALLED  BY  ELSE  OR  PENfil  CLEARS  PUSHDOWN  LSIT  WHEN  IF.  IF 
/*  ELSE  PAIR.  OR  BLOCK  IS  TERMINT  IS  TERMINATED.  CALLS  POPJP  TO  00  CLEARING.  */ 

OCL  ELFLAG  BIT(1>  INI T(  * 0*  B)  • 

7*  /*  POPUP  TOP  'IF*  “*/ 

POPl:  FLAG*' 0*  B: 

CALL  POPUP C • IF • * ; 

/*  /*  IS  LIST  EMPTY  ? */ 

END  POPIF: 

POPUP:  PROC(CM'ANO) : 

/*  /*  POPS  UP  1 STACK  LEVEL  (IN  EACH  OF  THE 
OCL  CMAND  CHAR(*1  VARYING: 

/*  /*  NO  LEVEL  CHANGE  IF  ENTRY  OR  ELSE'  */ 

IF  (FLAG)  THEN 

CLEVEL  = CLEVEL  - 1: 


3 LISTS).  DECREMENTS  CLEVEL  IF  FLAG 


*/ 


IF  I STACK!  CMAND)  THEN 
00: 

PUT  SKIP  LIST  ( ***ERRUR  IN  STACKl***): 
STOP: 

END: 

/*  /*  POPUP  l LEVEL  IN  EACH  STACK  */ 


FREE  STACKl. STACK2 . STACKS: 

END  popup: 

PUSHDON:  PROC(CMANO.LABL) ; 

7*  /*  ENTeftS  OP.  NAME  (E.G.  'IF')  IN  STACiU.  UP  TO  5 LABELS  In  STACK2,  CLEVEL  IN  STACK3.  STORAGE  FOR  THE 
/*  STACKS  IS  CONTROLLED,  ALLOCATED  IN  PJSrtJuN,  FREED  IN  POPUP  */ 

DCL  CMAND  CHAR ( * ) VAR. 

lablTs  ) Chart*')  var. 

X CEC  FIXED! 2)  : 

/*  /*  GET  PRESENT  LEVEL  */ 

X * STACKS; 

/*  /*  INCREMENT  LEVEL  UNLESS  ENTRY,  ELSE,  OR  IF  */ 

IF  (FLAG)  THEN 


x * X ♦ 1; 

/*  /*  PUSHDOWN  EACH  OF  3 STACKS 
ALLOCATE  STACKl, 


*/ 


Jjfe' 


$TACK2( 5»« 
STACK35 
STACK3  - X; 


2 

00010850 

3 

00010850 

2 

00010851 

2 

00010852 

2 

00010870 

*/ 

00010880 

2 

00010890 

*/ 

00010910 

2 

00010920 

*/ 

*/ 

00010930 

2 

00010940 

4 

00010940 

4 

00010960 

4 

00010980 

4 

00010990 

2 

00011000 

*/ 

2 

00011010 

2 

00011020 

*/ 

00011030 

*/ 

00011030 

2 

00011080 

*/ 

00011090 

2 

00011100 

2 

00011110 

*/ 

*/ 

00011120 

2 

00011370 

2 

000113S0 

*/ 

00011390 

2 

00011410 

*/ 

00011420 

2 

00011430 

3 

00011430 

2 

00011450 

4 

00011450 

4 

00011470 

4 

00011480 

4 

00011490 

*/ 

00011500 

2 

00011510 

2 

00011610 

2 

00011620 

*/ 

00011630 

*/ 

00011630 

2 

00011680 

3 

00011680 

3 

00011680 

*/ 

00011710 

2 

00011720 

*/ 

00011730 

2 

00011740 

3 

00011740 

*/ 

00011760 

2 

00011770 

3 

00011770 

3 

00011770 

2 

00011780 

* 


% 


* 6 
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STACkI  - CHANO: 
STACK2  * tABL: 


7*  /•  UP 0 AtE  CUP  RENT  CEVEC’~  */ 
C LEVEL  * STACK3; 
END  PUSHOON; 


00011790 

00011800 


•7 


00011820 

00011830 


PROC; 

# /*  CALLED  BY  PLEOIT  Oft  RETURN  FROM  READ  TO  CHECK  ON  PRESENT  STATUS  OF  IF.. .ELSE  STRUCTURES  ANO  DO  ANY 
-.NECESSARY.  UPDATING  Of  THE  PUSHDOWN  STOCKS  */ 

DCL  L BIN  FIXeDtl5*0T7 
THFL  * c; 


♦/ 

♦/ 


T 


/♦  /♦  ELSE  STATEMENT  ? ♦/ 

“T f Tsubs'tri l i ne ♦ I ♦ 5 1 '"STT6C5E  * i I nmaik "TUfiEtUSl 


”2 

2 


& ~ L. 


DO; 

CALL  ELSE; 


IlL$E;'il  Th6n" 


*/ 


TF^ThPX»T  kOBTHEN 

GO  TO  P3; 


"2 

4 

4 


00011850 

00011850 

TFOOITTOr 

00011890 

00011900 


00011910 


00011940 

BOOITWr 


ENO; 

/♦/♦KOI  is  TOP  OF  STACK  •IF*  ? 


AGINl; 


IF STACKI* •ELSE*  THEN 

CALL  POPUP! •ELSE* I i 
IF  STACKI** IF • THEN 


' :..?Y  ■ . 

•/ 


0001H 
00011960 
00011981 


l 


i 


do; 


DO  WHILE (STACKI** If 


M 

2 /* 


VEL«STACQ-L6 , 


LL  POPlfl 

end; 


' 'fern'll 


& 


>£V'j  ■. 

" 1 isasi  ' 


GO  TO  AGINl; 

»•••••»•*••+••••  *666  ••••••••••••»»» 


'RETURN; 


END; 


• ••  • • ♦ • •••••66666  • • • ••••66«  • 


♦/ 


/♦  /♦  VESt  IF  ST • IS  CCMPLETEDf  CHECK  OFF 
END  PUSHPULS 

9WS*  — — : : — ' 

lf«Ri  MEAD- IN  VALUES  OF  IMARGlN  UNITS  At  KARGIN)  ANO  OELMARG  t MARGI N INCREMENT)  THIS 


IN  VALUES  FOR  NESTING  LEVELS  1 - 9.  COMMENT  STATEMENTS  ARE  LEVEL  0 AND 


DCr~lMA_FTXEO"BTNT  IT.OT T 

MARGIN! 1 ) * 1 MARGIN ; 

00  IMA»2  TO  15; 


SETS  UP 
D MARGIN  IS  DEFINED 


A TABLE  OF 


AS  l 


“ MARGIN  (IMA) 

End; 

END  SMARG: 


MARGIN  LIMA  - 1)  ♦ OEtMARG;" 

. . . ,, ifiyf:  ‘ 


; «ffen5OTClN»'; 

/*  /*  WRITTEN  FDR  80  OR  120  COLUMN  PRINTOUT  (NCOL  - 72  OR  1161.  STORES  STATEMENT  TEXT  IN  BUFFER  IN 
/*  QUANTA,  ALLOWING  FOR  PREFIXES  ANO  LABELS.  DIVIDES, TEXT  AT  WORD  ENDS  IF  POSSIBLE  SEPARATES  FORE' 
7*  PARTS  BFSKlPCOOE  ANO' "STORES  THEN'  APPROPRIATELY.  */ ~ 


PRINT  LINE  */ 

ano-aft  */ 


00012160 

00012160 


■1  <L 

}< 

S-  v- 


DCL  (CFL «COMFL)  BIT!  11  lNlTt*0«B* « i ri ' 

OCL  (LP.LL.CCt  BIN  FIXE0!15<0I  INlTlZBIl 
“ DCL“TNCHAR‘.  'Kg;' AC,~Ni;“FC7V5iCrPI",FI'XED‘BI71ll5;D17' 


~rr 


03012160 
000 12220, 
00012230 


m 

m 


TLEV  DEC  FIXED (21* 
SOHLIN  CHAR(*I  VARYING; 
SXI-SeONO; 


00012240 

00012260 

00012260 


*r 


WSKIP  * SKIP ( RINDEX) ; 
FC  * CHCOOE! WSKIP. 11 ; 


-00012261' 

00012270 

00012280 

00012290' 

00012300 

00012310 


....  ..  


262  i 
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[ ' RC  = ChCCDE ( WSKIP.2)  : 

/*  /*  COMMENT  HAS  OIFF'T  PUNCT. . NO  PREFIX  */ 

IF  TYPE!  RINOEX I = LTYPEI7I  THcN 

od  : 

NCHAR  = NCOL  - 7: 

COMFL  = • i*B; 

GO  TO  again: 

/*  

end: 

/*  /*  NOT  COMMENT  */ 

NCHAR  = NCOL  - MG: 

00  NI  = 1 TO  5: 

LP  = LP  «■  LENGTHIPREFIXUINOEX.NI  ) ) ; 
LL  - LL  «•  LENGTH! LABEL (R I MDEX.NI ) I : 
END  : 

/*  /*  DC  PREFIX.  LABEL  NEED  SEPARATE  LINE!*)  ? */ 

IF  LP  ♦ LL  -•>  MG  THEN 
GO  TO  AGAIN: 

/*  

/*  /*  YES.  TOO  LONG  */ 

IF  LP  * ZB  THEN 
GO  TO  A2 : 

/*  • • • 

/*  /*  PREFIX  PRESENT:  GIVE  IT  A LINE  */ 

CC  * CC  ♦ ones; 

SKIPIRINDEX)  = FC: 

PT  = ACGPTR(RINOEX)  : 

LABEL! RINOEX.*  > = • • : 

TEXTIRINDEX) =• • : 

RINOEX  = PT; 

SEO«!RINCEX)=SEONO; 

/*  /*  NO  Vi  LABEL.  IF  ANY  */ 

/*  7*  SHORT  ENOUGH  TC  FIT  IN  MARGIN  ? */ 

IF  LL  <*  MG  THEN 
DO; 

CFL  = *1  1 B : 

GO  TO  AGAIN? 

/*  

END: 

/*  /*  LONGER.  SEPARATE  */ 

A2:  CC  - CC  ♦ ONEB: 

IF  CC  = CNEB  THEN 

SKIP(RINDSX)  = FC: 

ELSE 

ou : 

SKIPIRINDEx)  * o: 

PREFI  X!RINDEX.*>=*  • : 

TYPE! RINDEX)  = * • ; 

END: 

T EXT  !R  INDEX ) = # 1 : 

TEVELIR INDEX)  * TLEV; 

RINOEX  * ADDPTR! RINDEXI : 

SEO  #! R INOEX) =SEONO; 

/*  /*  SEPARATE  TEXT  INTO  PRINT  LINES.  STORE  */ 

AGAIN:  CC  - CC  ♦ ONEB; 

/*  /*  CASE:  PR  ♦ LABEL  < MARGIN  */ 

IF  CC  = CNEB  THEN 

SKIPIRINDEX)  = FC; 

/*  /♦  BUT  GENERALLY:  */  


2 00012320 
*/  00012330 

2 00012340 
4 00012340 
4 00012360 
4 00012370 
4 00012380 
..  */ 

4 00012390 
*/  00012400 

2 00012410 

3 00012420 
3 00012430 
3 00012440 
3 00012450 

*/  00012460 

2 00012470 

3 00012470 
..  */ 

*/  00012490 

2 00012500 

3 00012500 
• • */ 

*/  00012520 

2 00012530 
2 00012540 
2 00012550 
2 00012560 
2 00012561 
2 00012570 
2 00012571 
*/  00012580 

*/  00012590 

2 00012600 

4 00012600 
4 00012620 
4 00012630 

..  */ 

4 00012640 
*/  00012650 

2 00012660 
2 00012670 
* 3 00012670 

2 00012690 
4 00012690 
4 00012710 
4 00012720 
4 00012721 
4 00012730 
2 00012740 
2 00012750 
2 00012760 
2 00012761 
♦/  00012770 

2 00012780 

*/  00012790 

2 00012800 

3 00012800 
*/  00012820 


* T* 


I * 


Moo  f*  Butmrtt  Fo»mt.  Inc 


>- 


ELSE 


o: 


oo:  _ 

SK  IPIftlNDE  X ) 

IF  (CFL!  THEM 
_ CFL  * -CFL 5 
ELSE 

LABEL! RI NDEX ♦**  * 

PR  EFI XI R l NDEX  • ♦!  = *•; 

IF  !-*COMFL ) THEN 

TYPE IRINDEXl  = 

ELSE 

TYPEIRINDEXI  = LTYPE (71 « 


END; 

LEVELIRINDEXI  * 


tlev; 


/*  /♦  WILL  TEXT  FIT  IN  THIS  LINE  ? ♦/ 

if  lengtmsomlini  <*  nchar  then 

do: 

SOMlin: 


TEXTIRINDEX)  * 
GO  TO  TEXTOUT: 


/* 


END: 

/*  /*  NO,  SEPARATE  BETWEEN  WORDS  ♦/ 

DO  NI  = NCHAR  TO  I BY  -l : 

IF  ( SUB  STR( SGML  IN «NI « 1 ) * BLANK)  THEN 
GO  TO  linout: 


/* 


ro 

cr> 

Vjsl 


end: 

/*  /*  NO  BLANK  FOUND  */ 

ni  * nchir: 


LINOUT: 


TEXTIR INDEX!  * SUBSTR ( SOMLl N* 1 *NI  J ; 
SOHLIN  * SUBSTR!  SOMLIN*NI  ♦ 11; 

IF  SOMLIN  * •«  THEN 
GO  TO  TEXTOUT: 


/* 


RINDEX  * ADDPTRCRINDEX) 5 


SFOACRINDEXf *$EQNO; 
GO  TO  AGAIN: 


/• 


*/ 


/*  /*  TEXT  COMPLETE • CORRECT  SKIP  FOR  'AFTER* 

TEXTOUT:  I F CC  * CNEB  THEN 

SKIP(RINPEX)  « WSKIP; 

ELSE 

SK IP( RINDEX!  = RC: 

/*  /*  RETURN  */ 

END  STEXT: 

/*  /*  ALL  SUBROUTINES  AND  FUNCTIONS  HAVE  BEEN  INCLUDED 
END  PL  ED  IT; 


*/ 


j 

4 ft  
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2 00012830 
A 00012830 
4 00012850 

4 00012860 

5 00012860 

4 00012880 

5 00012880 
4 00012900 

4 00012910 

5 00012910 

4 0001293C 

5 00012930 
4 00012950 
2 00012960 

*/  00012970 

2 00012980 
4 00012980 
4 00013000 
4 00013010 

*/ 

4 0001302C 

*/  0001303C 

3 0001304C 

3 0001305C 

4 0001305C 
••••••••••••••  */ 

3l)001307C 
♦ / 0001308C  -idU 

2 000I309C 

-jnmrmc 

2 0001311C 

2 0001312C 

3 000T312C 
*/ 

2 00013140 
2 00013T41 
2 0001315C 

*/ 

*/  OO01316C 

2 0001317C 

3 0001317C 

2 0001319C 

3 0001319C 

*/  0001321C 

2 0001322C 
*/  0001323C 

1 0001324C 


aiak. 


— 


